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Abstract 

KUtLD is a Luol fur keeping modular systems in a consistent slate hj 1 managing the construction tasks (e.g. 
compilation, linking etc.) associated with such systems. El rmpluys a user supplied system model and a 
procedural description Of & las* 10 be performed in. order to perform the [ask. Ibis differs frnm existing, tonls 
which do not explicitly separate knowledge about systems from knowledge about how systems air 
manipulated. 

BUILD provides a Static framework for modeling Systems and handling ccmstructkm rcqucste thai makes use of 
programming, environment speciFic definitions, By Altering the set of definitions, dlilu can be emended to 
work with new programming environments and to perform new tasks. 
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I. Introduction 

Many programming languages encourage the development of modular ^Hcms by allowing the 
independent compilation of modules <AD,\ |Ada S3], C[Kernlghan and Ritchie 78], CI.U [LLsVov SI], 
L\>m:ri!ir.-I.Lsp [Stcvx £4]. VI cvj | M itchc 1 1 19\l I'his feature can be exploited to minrmiKC die amount of 
compilation that, needs 10 bt dune when SOfflC pun i>f A System, is changed. However, aS sySLCmfi become 
langer ii becomes difficult to know exactly which, modules need to be recompiled when one changes. It is. 
bnpLirtiint thai the correct modules be recompiled and relinked ■■ a bug caused by ignoring a module that 
should be rebuilt cat? be very difficult to find. JTiis problem is called the consistcm construction problem. 

This report dewribtS BUnr>. S tool th;U reconstructs syslcm modules in order (o ensure Chat thev are kept 
111 a consistent State. PUlin docs not modify source modules and will not rid systems of problems that require 
source code revision. However, ul.'ILIS car handle the many instances when: some portion of a system needs 
to he- recompiled. Felinted, or somehow repiucCS&ed in order to eliminate inconsistency. 

There arc many tools that manipulate systems by reconstrucunfl, incoitsi&iciir. puns Chapter 2 presents 
M,\ki: [Hcldman 79] and i3i:i"Svs3i:M [Wcinrcb and Moon SI], two representative tools, and drscusses some of 
dieir weaknesses. The fundamental problem with makt, nrrsv-gnrvi, and j3I similar construction directive 
based tools is that they opemte on systems by using, user supplied lisLs uf construction directives. These lisLs 
are difficult to understand. flUH.t} provides the same functionality as existing louls but dots SO without 
requiring yscrs In list construction steps. 

nuit.D derives the construction steps needed to produce a module from user supplied system iwdcft. 
These models specify how modules reference each other instead of how ihey arc constructed. riLULD uses the 
reference information to determine how modules depend cm each other and how a change to one mudule will 
eFfeet another, Kor instance, if a system model specifics that module . refers lo macros defined in muduhj, then 
BlJ3].r> can Infer that a change Lo module 2 implies thai mod\Ak } should be recompiled. Chapter 3 discusses 
system models and chapters 4, and 5 explain Ito* MJILD uses system models to perform construction. 

The major Strength of BUILD'S reference hascd modeling system over a construction directive based system 
JS chat it provides a higher level language for describing system structure, itecause It eliminates low level 
construction detail and allows explicit declaration of high Level system relationships, a reference based model 
is easier lu understand and provides more in formation than its construction directive based counterpart 

BUILL> separates knowledge about systems from knowledge about how systems are manipulated. The term 
I&sA Is used to refer to a construction process such as compilation or linking that nutt n may he caLled upon to 
pcrfiimr, WJlin uses ttj$& descriptions to specify how to perform construction msks and how the various liinds 
of references that appear in s^icm models may effect die construction required lo perform the tasL Using 
the example frum the previous paragraph, BLILu s tasfc description for compilation allows it to realize that 
while a change to module 1 implies that mLKftrj'c T should be recompiled, a change to modttkj does not imply 
that module 2 should be recompiled. 



iiwrow 

T1PTTOQMP is an tjsamplc L>fit HH*duSiJir system- it will he used ihrtiugfujul this rcpnfl. Ecu presctil dilTerent 
nspcctH 4.I--T system eoniynicikHi uxiK [.Lhi* cinmplc was udaptttJ J'nmi unc used toy reldnun [Kclidmari 79|)l 
iiwrow Iuls iwo rruijiic ttKHJuks. it paracr and a ende eencratwr. Ihc parser re bank by \.\OC, a parser 
ytnl?r;iciiig L« ? l hi jJiihllStHl 78;i|. \tiQ cudc £ic-ncr;itor is impkvncn L*d in C|Kcrnighan ulld Rilcllie 78J. Hie 
pirsLi !iJ '."!■.: iv tii -r 1 1^0 . : .v.iv.m.i" scl i:l "i.kliiii:.u-i ^ l;r slu iJ J-.ii> ^t in. - '..iV< I'hos. Mollnii :i-k mtc- 
ttutlbiiicd with U*C source pn.F£r,ims during affltpllUlitn. The Cufllpilcd progMin^ .jrc WnYzd *ilh m lihrary 
[hm is- -iilsii sut>jcct la change, Kigurc 1-E depicts iinycQM i>'s inter- tnwJulc referents p^Mern and figure 
1-2 depJclsTINYCOM^MnslnKlkm proem. 
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Fig* re l-Zr Cnrotructmn Graph FoniNYCOMP 



Hcfenrnev Itascd System Models 

C;uin;iic I'i^uic 1-3 which ccmtainFi |hc MA KJ- directives fitf "I1NYODM I", and fi&tfre 1*4 which umLainH lEic 
1iUIIJ> system model fur nNYaiMi 1 . While the MaKI: directives enable tinycomp's construction graph, 
i5L ■ n'sM-sCk/ni rrHnJcltntodcs'nNvnoMP'Rjiefcrewctrjph. 

A reference imsdcl can be used in pLicc Jif a onusl ruction directive list because jl1I «f the inmrmatioii about 
construction present in ■sudi a fost can be derived Fnim a reference ■model. Consider (he third uaki; directive 
furTWYCPMI*; 

CODEGEN.O: COOEGFN.C UErlNITIQHS.C 

CC -C CODEGEN P C H -C COMPILES 

This expresses that CODEGEN.O is pmduccd bj compiling CODEGEN.C. and thai if cither CODEGEN.C or 
DEFIN1T10HS.C changes, then CODEGEN.C needs to be reeimpited. 'Phis construction dependency exists 
boc-dinc CODEGEN.C isannbinttl with DEFINITIQNS.C when it is onmpildd hj produce COD EC EH.O. 

In contrast, the reference based mudei specifies that CODE-GENE RAIOft /nc/WfiDEFS: 
f j INCLUDES CODE- GENERATOR DEF5) 
iiuiui's. description for cwnpilattori contains die tnuwiedge ch^[ the : INCLUDES rcferejKe implies a 
compilation eonsiructicm dependency between tnctudmg and included fiJcs. 

PARSER. C: PARSER. GRAMMAR. 

YACC PARSFR.GKAMMAP #YACC MAKES IT. TAB. C 

MV YIABC PARSER, C #(^t NAME Y.TAB.C 

PARSER. Oj PARSER. C OEF IMITIONS . C 

CC -C PARStR.C # -C COMPILES 

CODEGEN.O: CODEGEN.C DEFINITIONS. C 

CC -C CODE GEN t C # -C COMPILES 

TJHYCOHFr CODEGEN.O PARSER. LIBRARY, 

CC CDDEGKN.O PARSE P. LIBRARY. -0 TINYCOHP # -Q LINKS 

Figure 1-3: MatcFilc FnrTINYCCiMP 



(DEFMODEL TIHYCONP 

(: MODULE DE F5 :C-SQURCE "DEFINITIONS™ J 
fiMODUiE PARSER i^ACC -GRAMMAR "PARSER"} 
[tNODULE CODE -GENERATOR ;C-SOURCE "CODEGEN") 
f: MODULE LIBRARY :C-OBJECT "LIBRAHY") 

{: INCLUDES PARSER DEES) 
{; INCLUDES CODE-GENERATOR DEFS) 
(: CALLS PARSER LIBRARY) 
(:CALL5 PARSER CODE -GENERATOR) 
(; CALLS CODE -GENERATOR LIBRARY)) 

Figure 1-4: PLIED Model Far iinyCOmp 



Task tkHTiptions 

Upon rcecipl of a request lei perfiirm a task, lll.TEJl derives a task gjuph which models Hie conStmcdOBi 
steps .jtid. dependencies necessary to perform Hie task. (Chapter 4 presents HUH n tisk nrndels, and chapEcr 
5e*pt;iins how task mnttcls are derived frum. sysiem models.! Once die task, irmdel bus been denvud, hlii.ei 
analyzes ii in cmkr to determine which eorrtpiMienis have changed and what steps are needed in order to 
satisl} 1 Hie task tv^ikSL. 

iii.i]i.i> piuvldes a static framework. Tor modeling systems, and handling cons^Riction requests that mokes 
use trf programming cnvirnnnKM specific definitions. New tusks qui be added id ijuillVs repertoire by 
altering die set of dcfiniiionfi, 

h'or cfciinfiplc figure 1-S autLAins. the forms needed Et> define a Disk called : (. TST~SOUfiCE ■ CODE which 
produces formatted listings df the- source modules of a lisp system, (litis example will be explained In detail 
in chapter 5.) 'J he first form allows MJIt.ll to represent the processing needed to list a single Lisp source: file. 
The second form tells IJUEIJ1 what to do when a : L 1ST -SOURCE -CODE request Ls received. Ihe last two 
forms tell lllJH.n ahout the imphcaLitms of the references : CALLS und ; MACRO-CALLS upun die 
:Ll5T-SQURCE-CODE task. 

Since task definitions are separate fmm system models new tasks can be performed cm existing modeh 
without additional effort hot instance, once : L 1ST -SOURCE -CODE has. been defined, fltll l> will be Able to 
handle requests Jli formal the source code for existing systems without chunking, any system models. 
Construction directive based tools cannot be extended in 11 similar manner. 



(DEFINE -PflOCESS-TYPE :L1ST-L1SP-S0URCE 
{{SOURCE : LISP-SOURCE :SIWGLE)) 
{(LISTING : PRESS : SINGLE SOURCE)) 
OUTPUT -SI REAM 
(FORMAT OUTPUT-STREAM "-1LIST -A" 

( PATHNAME -MINUS-VERS TON SOURCE} > 
(FORMAT OUTPUT-STREAM "^LISTING -A" SOURCE) 
(LIST-LISP-FILE SOURCE LISTING)) 

(DEFINE-REQUE5T-MANDLER ( :L 1ST -SOURCE -CODE : LISP-SOURCE :PRE) 

(SOURCE -NODE) 
<ACfT£5S- SOURCE-NOUE ((SOURCE : LIST -LISP-SOURCE J LIST IMG))) 

(DnFIHC-RcFERENCE-HANty em ({ :MACRO-CALLS :LISP-SOURCE ;LISP-SOURCE) 

(:LIST-S0UfiCE-CODE :LEFT)) 
(IGNORE CALLlU-NQDE) 
(PROCESS-REQUEST :LIST-50URCE-CGOE CALLED-NQDE)) 

(DEFINE-REFERENCE-HANDLER ((:CALLS :LISP-SOURCE : LISP -SOURCE) 

(■LIST-SOURCECODE :LEFT)) 
(IGNORE CALLED-NODE) 
(PROCESS-RE0UE5I r L IST-SOURCE-COGC CALLEO-HODE )) 



FlCiiirc 1-5: Definition For :l IST-SOURCE-CODE 



2, System Construction Tools 



ITi is chapter focuses on two lools that wgrc desiencd to aid in (be mjinn^ement of the consistent 
construction pmhlcm. Itehuc- Ihry jit presented some tenminotng}' that will be used thm-ugh i iut Uiis repon, is 
introduced- 

|>j1Fcrcnt programming envimnmenls \itc geared t» operate upon diflcrenl kinds of ohjccls. for instance, 
stmie environments are designed to operate mil files, and others on functions. Ihr term gnj^j will he used to 
nefer to the nbjtLts manipulated in a programming environment - regardless of LilCir nature. 

I lit- termiFiii'iMgy hitrnduccd in this paragraph will he used to refer to the kinds- of grains that are 
manipulated during the construction process, Sonne grains are the components diat arc produced by people 
and not programs [c^u programming lanjiuajc source code). Source grains arc manipulated by programs to 
produce Jmrtrf grains (eg,, inject code), Grains thai ure ihc final prod wis of the construction process are 
called ijw^giiiins (eg., executable images, of programs). While goal grains itrc usually derived grains, they can 
also he source grains. I >crived grains thai Lire Tint goal grains are called ititerHtfUietc grains (e.g., object code 
dint requires hnking in under tu form ciccutahlc images f. 

2.1 MAKE 

M.\Ki:[! : eldman 79J, available as. part of UNIX 1 , is a simple tool fin managing systems, diat has received 
widespread use. WAKE is driven by sets oF construction directives that fonn '"recipes" fur constructing 
systems, These di receives are -stored in a text file called a Make Kile and have ihc form; 

TARGET-GRAIN : INGREDIENT-GRAIN- 1 INGREDIENT -GRAIN -2 Prr 
COMMAND -1 
COMMAND-! 



l-jcti entry declares Lhat TARGE T- 5RAIN depends on each of the grains to the right of the colon. Lhc 
command sequence below th^ construction dependency declaration line i& executed in order to cunsirurt 
TARGE T -GRAIN, There arc no constraints placed on the ■commands which can Appear in the command 
sequence. FuTihenrLnrc, there arc no iwdcrinj; nates for Make Kite entries, 

M.iKT has a simple mar no subsULution facility. A macro is defined in the following manner: 

MACRO- NAME^MA CRO - EXPANS I ON 

Any instance of MACRO- NAMC enclosed within parentheses and preceded by a. dollar sign (ie.. 
J( MACRO-NAME >} is replaced by the text MACfld -EXPANSION when the MaVcKite that includes the macro 
definition is prucesscd. The definition for a macro musi precede all cvf its uses. 

A Small Ftiirtiplfi -TTNYmW 

Kigure 2-i depicts the construction process fhr nNYroiW and figure 2>2 contains a corresponding 
MakcK'ilc. Given the MakcHle, mam: will perform Lhc appropriate ennstructinn when TINYrouP 
CLimponcnLs change, For instance, a change to PARSEH.ERAMHAH will cause a new parccr Lo be derived, 
Compiled, and linked. A change to COlttGEH.C will cause CODEGEN.C Lo he compiled and linked, A 
chance [o OE 1 3 Ml t IONS.C will cause PAFt$t R.C and COoeGEN.t to be compiled and linked, Finally, a 
change to L IBRARY . will cause linking hut no compiling. 
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Kituw 2-1: Construction Gr.Bf>h For TINYCQMF 



PARSER, C: PARSER. GRAMMAR 

YACC PARSt P. GRAMMAR *YACC MAKFS V,TAR r C 
MV Y r TAB.C PARSER. C (CREHAHE Y.IAB.C 

PARSER. Oi PARSER. C DEFINITIONS,: 

CC -C PARSE R.C f -C CDMPILE5 

CDl^fiHN.D: COUFGFN.C DEF IHITIOJUS.C 

CC -C COPE GEN. C f -C COMPILES 

TIk*C0MP: CODEGEIJ.D PARSER. LIBRARY. 

CC CQDEGEN.Q PARSER. Q LIBRARY. -0 TINrCOHP M -0 LINKS 



Figure 2- 1; MateFLle Few TlimxftfP 

The MakeFfle entries art interpreted in the following manner: 

PARSER. C: PARSER. GRAMMAR ... 
PA R 5 E R . C depeudi nil PA RS L Ft . GRAMMAR, ll ii treated by running YACC on PARSE R . G R AHMAR. 

PARSER,^: PARSER, C DEFINITIONS, C rr . 

PARSE R.DdcpcndiHin PARSE R.C and DEF I NIT I0H5.C. Il litlNMlodty fttCWIpiling PAKSt R . C. 



CODEGEN.D: CODEGEN.C DEFINITIONS. C ... 
CODE GE*J .0 depend* <m COnl Gf N , C and DE F IN 1 T IONS -C ti is created hy mnrnpiling CODE GEN . C. 

TIHYCQMP: CODEGEN.O PARSER. LIBRARY. ... 
1 1 NV COM P depends on C ODE (i E ■ . 0. PARSE R . 0, and L I B R ARY . , It is treated b y rclin* ing the system. 



The Cvn-iitnictinn Process 

Mak\ : is invoked vt'Hh the following UNlXftBnmaiid line template (bractets indicate- opuiT.al fields): 

MAKE [-T MAKEFILE] [QPIJOti ... ] [MRSf r-fiMJWJ 

MAKEFILE Sped fics the name n-f the file containing the construction directives, if nu -T upturn is used 

Ihcn MAKlv uses (he file named MAKE F JLE in the working directory-. 

OPTION Specifies options like prnrf &rf cfo nrjf jjf«?ufp ^if camtuatMf setftuWtS UT update the 

modified date of the targets without executing uny command sequences* 

TARGET -GRAIN Specifies the name of the target grain to be processed, if TAKflFT-GflArw is not specified 
then ma KT will process the first target grain named in the Makefile. 

MAKI : . hegins by constructing a dependency graph From the selected Mjfcckile. Rach node tn (he graph 
aurc-sponds to a grain mentioned in the Make Kile, ['he children n\'a node represent Ihc grains that the grain 
represented by die nude depends on. A request to wraJkr it uifget grain i* processed by doing a depth- tint 
walk of the graph Planing with ihe node that corresponds to the target. At each iukIc visited, any grains that 
i\rc missing («■ whose children have changed are updated, 

.UAKt : compares (he creation dates of a target gnu'n and its ingredient grains as an approximate means of 
noting when changes occur. Kor instance if TARGET- 1 depends tin INGREDIENT-1 then MaK| : will assume 
mat INGREDIENT- 1 lias changed if and only if its creation date li after die crealum dale of TAflGET-1. 
Since UNIX allows file creation dales to be modified by users, it ks possible to fool make t>v changing file 
attributes, However, since most people do not change file attributes, the Ma K £ .mechanism is reasonabit 

Without information ahout how an ingredient bas changed, maki; cannot determine whether a change is 
significant or not. 'Jhercforc. MAFtf. pcssjmisucaHy assumes that every change to an ingredient grain will 
effect the target grain, and it will always rcvusisiruct a target *hen one of its ingredients has changed. Figure 
2- 3 contains the make construction algorithm written Ln Lisp\ 



[DEFUN MAKE {NODE) 

(COLIST (CHILD (GET -CHILDREN NODE)) 

(MAKE CHILD)) 
(IF (OR (N0N-EXI5TENT-P NODE) (.CH1LDREN-CHAN&ED-P MODE)) 
(OPOATE N0DEH)' 

(DEFUN CHILDREN-CNANGEO-P (NODE) 

{< (CREATION-DATE NODE) 
(APPLY #'MA* 

(MAPCAR # 'GET -CREATION-DATE (GET-CHILDREN NODE)!))) 

I'igure 2-3: make Construction Algorithm 



Ad Extended Sample - LINT 

TllC i INI s^icm [Johnson "78b| is presented as an extended example i>r using MaKIj, LINT examines C 
source programs and detceU bugs dial most C compilers can not. It is slso sensitive ui constructs that arc legal 
but may not he portable. 

nvr consists of a UNIX shell script driver, a sei of lint l.ihrory fitctk and two C pntgrams. Ucforc 
programs air. processed by lite first C program (i-C^ the first pjLss of I. INT), they arc prnec&cd by the C 
prc-pruL-cssiir. which handles, macro cupunsion and some compiler directives. 

After being processed by the C pre*processor L pnsgrams arc sent to the first pass csT US' J. I his pass does 
lexiirnl analysis Oh the input text. constructs and maintain;; symhol tables, arid build* trees firf expressions.. An 
intormodtalC file that consists of lines of ASCII lext k pra^inccd. t'jch lint contains irt external identifier 
name, an encoding of the onntext in which it was seen (use, dcfinituiii. declaration, etc. I, a type specifier, and a 
source rile name and line number. The information about variables local to) a function or file is collected by 
accessing (he symbol Lubie, and examining the expression trees. Comments, shout local problems are 
produced us detected. 'J he information about external n..imcs is collected in me intenncdLaic Tile. 

LINT libraries, are collections of definitions nf external names thaL arc appended to die intermediate file 
generated by the first, pass of lint, 'ITicv arc used to provide i inT with a set of definitions for commonly used 
external name* without processing the source thai contains Uic definitions, The most commonly used 
libraries contain the definitinns for" die functions dlat at* supplied by the UNIX C ran time environment. 
Users can create their nwn libraries of commonly used names in order hi alleviate repeated processing. 

After all the source files and library descriptions have been collected. Ihe intermediate file is sorted tin 
bring all infonnaUM collected about * given external name together. J he second pass of IJNT then reads the 
ii.-; li : mi ih. - - n^-iiio..:. ■!:•.■ i'L: .aw. i.nnji. tjs .1':' o; Ih-.' d-.'!i"i ■■•■"■■■ J-.-: ; nLkw.s. .!":U us.- vi a'l'MMi'r;)'. 

l-'igure 2-4 contains the MaleKik for l.l NT. Ihe primary pturtl of this eJUMllpk is that MafccFiles* even for 
medium si:(ed systems like IJv(> are difficult to understand, I Tie BUILD description mechanism introduced in 
chapter 3 provides a much simpler way to describe systems. 

The first part of the IJNT rvfatcFilc contains macro definitions. These definitions are used to Specify 
directories (e.g.. K>, compilation flags (e.g., C FLAGS), and to group files (e.g.. LINTLJ.B5}. J]w target ALL is 
used to name Ihe major Subsystems, of The LINT, The r\<K cluster of spccificarions manages me first pass of 
lust, There is an cntrj- for each library file provided with tint. Kach of these specifics that a tint library file 
is dependent Upon a library source fclc and the First pass of LINT. Libraries depend on the firtt pass uf LINT 
hceausc they arc constructed by iL The targets that Specify management for the second pass of UNT are 
LPAS.£2andLPASS2.0. 

Ihe LI H7 ALL, INSTALL. SHRINK, aid CLLAfl targets are not grains at all, lather, they are used (o 
intliate installation and removal of UNT. A request to make any of these will always result in the associated 
command sequence being executed because the corresponding, files do nnt exist Ln the UNIX envLranmenL 
Th« use of non-existing grains In force command sequences to he executed is a popular and useful feature of 
MaKT". The Functionally provided by these Lojgct grains is an example of liinv ConstTuClion tools can be used 
for more than just system construction. 



M=/LJ5R/5Ht/ LIB/HIP 
CfLASS'-O -ftFLIHHAMES 

LIUTLIFJS'LLIE^FDRT.LH LLlB-lE.LH LLIB-lM.LFJ LL1B-LNP. LH LL L6-lCURSf S,. I Fi 
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LPASS) 
riEES.Oi 

LINT O: 

SCAN.-?; 
ADEF5.Q: 
CGwut.Q: 
CGF1AH.0 



I, PASS I LPA&FjJ t CLINT LIBS] 

CGAAN.O JDEF5.0 SCAN.O CQHH1.0 PFTK.O TflllS.D GPTINj.O LIH1 .0 FU5H.0 

EC CGRAH.O KOLFS.O SCftM.O COMHS.O FFTN.O TREES. OPTIM.D LE&T.O HASH.D -0 LPASS] 



IfHJifMAHIhh.Sl HACUE F S J(M)yHFIIM j [N J/T ft| ES.C 
CC -C S(CFLfifiS| -]Jj*l> -]. HMJ/TAFtS.C 

I(N|. , HAMrt5I H^CnEF5 i(M)/HFILEl 3[H)/0RTIH.C 
CC -C SlCFIflCSJ -3S<H} -] HH)/0-J"r|H.C 
J(HJ/HflHlH5l HACI3B F S 1 [ M j ..' MF I I t 1 $ ( M J r PF t M . C 

..■: c s;;.i i ■".lii .i:"; '. s^j/pi n.c 

S(N,)/*|A.FJIFEST NACDEF5 J(M)/MF : ILF] lhanifest 
CC -t tfCFLACS] -lt<»} -I. LTHT.C 
J(Nj/H4hlF<^l KACLUfS $(H)SHMLL] SlMj/SCAH.C 
CC -L KCFLAG5) -El(N'| -I. 1<M>/SCAN.C 
S{M)/HftHTFIST S(HJ/WILEt HftCDE FJ i{M)/XPEFS C 

cc -a (({FLAGS] -[$(«) -t. ((H»/jEQirs.c 

Hhj/'iirt.iiiriLsr n«)/Hi]L[t ki*;/cohhdii haecets s(H)/cohmi.c 

CC -E KCF4.AG5] -[. ]S[HJ KFi[/COHHL . L" 

J{M)/FMJ|]l!£r HH)/HI.1LFI MAlCDi I $ CGFtAH.C 
CC -C i(CrtAG£) -tl(N) -[. CCflAM.C 



KH.4N.C- t{H)/CGNAM.Y 

¥fc£C J|JMJ)/CGRMI.V 
FW V. TAB C CtflflH.C 

LL]fl-PORT,LU: LLlB-PflflT LPASfil 

-j/LIB/CPP -C -DLIBT LLJB'POtT | ./LPA551 -fLFY > LLIB-PCWT, LN J 
LUB-LH.LH: LlIFJ-m LFASSl 

-i|/L]fi/CPP -t -ftLIilT LLIfl-LH | ./LPASS1 -PIN > LLIFJ-LK.LN } 
LLIFJ-LWP.LN: LLIFJ-UHP LFASSl 

-(/l]B/CPP -t -FTUHf LLIB-1HP | ./LPJ15S1 -PUV > LL Ifi-LNP.LH ) 
LLI8-LC.LU: IlIFJ-LE LPASSi 

-(/LIFJ/CPP -C -W.INT LLIB-LC | . /LPA$Sl -V > LLlEt-Lt.LN J 
LUFJ-LCWStS IN; LLII-LCUFISE5 LPASSI 

-(/LIB/CPP -C -H.IHT LLIB'LCUR&ES- | VLFASS1 -V J> LLJB-LCUB5E&. LN > 

IPA$$Z: IPASSZ.O FULSD.Q 

CC LPAS12.Q llASH.O -0 LPASS2 

LPASSi. Or S{*]/l«NlFE5r LMAKlF^FSf 

CC ((CFLAGS) -C -l^K} -I. LPASS I. C 

LINT ALL: 

MNT -UPV -I. -lt(H> $(M)/CGflAN.C «« ) / JIDE F5 . C J(N]/SCJMI.C V 
S(N)/PFTFi.C Sf l N)/THEES.C S(HJ/DPTIH.C LINT.C 
INSTALL: ALL 5HELL 

■ ■Stjlij -s lpaS5i /iii;k/l [H/L ] yi/i ]Nri 

INSTALL S. LF«S2 /(JSR/L [FJ/LIHT'L JNT2 

FOP I IN LLIFJ-"; 00 INSTALL -C -N 6*4 tit 'USfl/L I B7 L I ■! ! POKE 

[K$lAll -C SHtLL /LjSFt/ft[H/Ll«I 
SKRINk: 

HH -F *.Q 

ClEAH; SKAJNK 

RN -I LPdSSl LPASS2 CGRAN.C S{LINTLIBS> 



Fi^orel-4: MakcHlc Por IJNT 



Deficiencies 

riiu.vi-d in Icriuv of coflstmcrlirtn. ITlC fundamental problem, with M.NK.1-: r dial il forces users 10 
manipulate lists of construction directives, People do not normally LhLnk about systems in tenris of the steps 
used to cortaruct diem, and therefore these list* arc difficult to understand, mafci- should present a more 
natural user m retrace and then wort from the user supplied information towards die construct n information 
that ii requires. 

MAKIi dkKS ihk include an adequate means Fur Saving and reusing diimiiwn construction patterns. The 
introduction of such a facility would shorten MaU^lles since common patterns would be replaced with single 
identifiers. Tne definition of the identifier would document and high light the i mended cnnsl ruction pattern. 
The functionality described in this paragraph is usually provided by a macro mechanism, however the M\rtE 
macm facility is Lou- simple "■ it does not even allow fin parameterized macros. 

Nd underlying L;is^ dfsi'iipti*!**- Syslcms 1h.it keep fcnnwlcdgc about consLructiun separate (rum 
Knowledge ubuui systems can he emended hy adding tn the construction knowledge without altering existing 
system models. Pitman [Pitman %4\ deacus&cx the importance trrf separating knowledge about systems from 
knowledge about construction us3hl makm does not use tits* descriptions at all and cannot be extended 
without changing existing MakeHles. 

Inlcnnediati: grains: are referent wl. Mainiainers can only change systems by manipulating Bounce grains pr 
requesting libit gjttil grains be constructed. Main Itinera do not manipulate intermediate grains and it wuuld 
be nice if these grains did. not need In appear in Vlatcl-'ilcs. 

All source Rjairis neud not he referenced. MAPU: ul lows System dtsei iptinrl-s tin urn it sou IX* grains that am 
also goal grains since there is no command sequence Ulat uses uf effects them. rOf example, (here k£ nothing 
that forces UNIX Shell Scripts to be included in MakcFtlcs, The absence of references tn Shell Scripts would 
be a serious omission if someone were using a Makefile to determine which grains needed to be copied when 
transporting a system. 



2.2 DEFSVSTEM 

ni;i*YSJ"i:w [Weioreb and Mtion 81J is n eonstniclioii dinwlJi'c hitscd tool that is. used lo install and 
maintain J Jsp Machine software. The I MSYSHW analog to maki's Makefile is called a system description. 
nniSYiTMM System dc^cripniiiss contain .1 mixture of system modeling in formation and conslructinn 
ciKUhO ih-is"k v requires I"...- .> - in 1 :.l -c4in.-r1-.-c- iclke li,imf:riiuUn:s) be Ibnr.alk defined before 
ihey arc used; this is different from the MAKR approach of allowing unlimited use of UNIX command 
sequences; 

System deseri pe ions arc made by D E F SY ST EH macro, Calls lt» 0£ FSVSTEM have the form : 

{DIFSl'STEM SYSTEM-NAME 
{KEYWORD AttGS . . .) 
( KEYWORD rffTGS . . . ) 

Ilic options selected by die keywords fall intn two general categories: properties of the system and 
Irans-FormationS, 

There art three main WJ^YSTHM property keywords: 

! HAHE Srj»d ftCA a '"prett/ 1 version of S VSTFH - NAWE lor use in pi inling. 

: PATHNAME-DEFAULT 

Specifics a local default within the definition of die system for strings to be parsed into 
pathnames. 

; MGOUL.E Assigns a name to a group of files within ihc system. 

A transformation is (in operation, such as compiling at loading, (hat take? one or more files and performs 
some operation on them. Ihcie are livo types of UJil-SYSIW transformations: -simple and complc*. A simple 
transformation is a single operation Old a module, such as compiling it or luading il_ A GOmplea 
transformation combines several transformations; for example, compiling and then loading the results of die 

Compilation, 

The general format of a simple transformation Is: 
(JMUE TWPUT PRE -CONDITIONS) 

NAME The name of the transformation to be performed On [hi files Specified by IrVPUT. 

Examples of transformation names arc ; FAS LOAD and r COW I IE -LOAD- J NIT (these 
transformations arc described below). 

INPU r A module or nested transformation. 

PRl- CONDITIONS 

Optional. Specifics transformations that must oocuf before the Current IM nsformation 
itself can late place. The form at is cither a list f NAME MO001 E -NAMES , , . ), or a List of 
such lists. Kach of ihese lists declares diat the transformation JYAHf must be pcrfofmed on 
the named modules before the current transformation can take place. (Ihc Lisp Machine 
documental ion calls pre-ennditions >icpefidnicTEX.) 



Ihc Pulkiwiri£*impk tnittsformat ions ^rc pre-defined: 

ifASLOAD r mds the indicated Ilk when a newer version of ihc 111c ciLsls than was re-ad into the 

current environment. 

: COMPILE Compile* the ondicatcd file when the source file h:is hecn been updated simc the eunipilcd 

code file mi whiten , 

Unhke sample 1rans.rf1nnati1.vn5. complex transformation* du not have ail) - standard form. 'Ihc predefined 
cum plot trans formaliuuS are: 

r COMPILE -LOAD 
Compiles and then loads Ihc input fik*. It lu& UlC form: 

( : COM P I LE - LOAD IHPU T CQMP I L E -CQND I T IONS LOAD- CONO IT IONS) 

and b exactly the some as 

f;FA5L0AD £ : COMPILE INPUT COMPlLC-CONDITIOHS) LOAD-CONDITIONS) 

:COMPILE-LOAD-IIIIT 

CtJirpik-s LinJ k^ids the input flics. This iranshirmalion is sensitive to changei made to an additional 
dependency list It has <hr form: 

(:C0MPILE-LQAD-INI7 INPUT AD0inOHAL'DfP£N0ENCl¥S 
COMF1 LE-PRi- CONDI T IQHS LOAD - PRE - CONO IT IONS) 
INPUT will Ik compiled and loaded whenever its soutec flic or any of (he modules listed Lit 
AODUJONAL-DEPENOENCIES ,irc updated. Nutc, the AODI TIUN&L -DtPlfflENCItS field of this 
transformation specifies the same kind of construction dependency as rvtakeFilc entries da 

It is important to distinguish between transformation declarations and tfansfotmittlon references. 
Transformations arc declared by keyword lists in raJJs to DE F5rSlEM. Transformation* are jeforcneed in 
precondition ItSES. The l/ansfijE'niatkjns referenced in a. pre-condition list must he declared somewhere- in the 
system description. 

DEzE-TsYSlTlM contilns a facility for defining new transformations. Sew simple transformations are defined 
U3m£u\cDEFIII£- 5 INPLWRAHS FORMATION macm. Calls have the form: 

(UEK IKE -SIMPLE -TRANSFORMATION NAME FUNCTION OE FAULT -CONDITION 

INPUT -FILE-TYPES OUTPUI-FILE-TYPES) 

NAHE The name of the transformation being defined. 

FUNCTION A (unction to be called when the transformation, is performed. 

DEFAULT -CONDITION 

The function that is called in order to detcfnlDG If the transformation should to 
performed. 

INPUT- FILE -TYPES 

Specifies the types of the input files to ihc transformation. Lisp leadline file type 
Specifics! ions arc filename extensions £c_g., "lisp" 0* "bin"). 

OVTPUT-FILE-TYPES 

Specifies the types of the output files produced by the transformation. 

Few ex^mpSe, 10 define <i simple uansfomahon tailed : LI5P-TACC dwt CaHs L ISP-YACC to derive paraer; 
written in l.isp from HNF grammars, die following definition could he made, ([fa Utility nkc YkCC wen: 



desired on The Lisp Machine it would probably be implcmciHed with a macro and nut a separate parser 

g ■ i ■• >' • ;•• TOftU 

(DEFIHt-SlMPLC-TRANSFORHATION ^ISP-fACC * r LlSP-YACC 
*"FILE-NttfLR-TI1AN-riLE-P (:GRAMMAR) (:IISP)) 

L ISP-YACC will be invoked whenever the input tile (U,. [he gJiUtimar} ii MWff lhan (he output fito (i.e., [he 
parser), in otfMJr winds, die transformation will he performed whenever die source file IS updared. Notice 
diat [his UdciifiMirMirion rdieiun grain creation dares in Cecily the same way that Make; docs. 

QimpkK trajirsformiiiions are defined as J.isp macros, Here is the definition of the iCOHPlLE-LQAD 
transformation that was described earlier: 

(Qt»HACR0 {; COMPILE -LOAD DETSYSTEM-MACRO) 

(INPUT *DPTIOJilfll. COMPILt-PRE-CONDITIOHS LOAD-PfiE-COHDI U0N5 ) 
'([FASLOAD (: COMPILE .INPUT , COMPILE -PRE-COMO IT IONS) 
^LOAD-PRE-CONDITIONS}) 

K Small Esample -TTMCOMr* 

Figure 2-5 Cimcaini die LH-TBYSrriW deseripUon for a Lisp implementation of Tl NYCOMP. 

fbl.tSYSiEN rjNrCGMF 

(:MDDULE CEFS "DEFIfl i T IONS") 

( i MODULE PARSER "PARSER") 

{: MODULE COUr I'ifNffiATOR "COOEGEN") 

{: MODULE LIBRARV "LIBRARY") 



FASLOAD CFFS) 

FASLOAD LIBRARY) 

CQMPlLE-LuAD^IMII COCE-GEHEflATOR {DEFS) (;FA5LQAD DEFS)) 



(:COHPILE-LOAD-INIT fjLISP-YACC PARSER) fOEFS) f ; FASLOAD DEFS})) 

Figure 1-5: DEl-'SYSllM DcscripUonForTTNYiCOMP 

The nwcoMP description contains a set of modufe definitions followed by a scries of transformations. 

The [fansformaLions. m the description have the following interpretation.: 

(:FASL0A0 OEfS) 

Specifies that OEFS should be loaded whenever it is updated. There arc no pre-conditions to be satisfied 
before (he loading can take place, 

(5FASL0AD LIBRARY) 
Specifies that LIBRARY ■should be loaded whenever it is updated- There are no pre-COndMotlS to be 
satisfied before the loading can rake place. 

f :COMPILE-LOAD-INIT CODE -GENERATOR (Ot'fS) { : FA5L0AD DEFS)) 
Specifics that CODE -GENERATOR should be be compitod and loaded whenever it or DE FS changes. Before 
Ihe compilation can take place, CtE FS must be loaded. 

(: COMPILE- LOAD- IN IT (:LISP-TACC PARSER) (DEFSJ (: FAS LOAD OEFS)) 
Specifies Hi a I a paiser derived from PARSER ii to be compiled and loaded- A new parser b produced 
whenever PARSER changes. The compiler and loader are invoked whenever DEFS or the derived parser 
CtliflgCS. iLISP-VACC will not he invoked if only DtFS ellangfiS. I'rior to mmpiliilmn. OEFS must be 
1l bided. 



The f. 'obstruction Process 

Systems previously modeled With DEf SYSTEM arc constructed by calling HAKE -SYSTEM. Calls have the 
form': 

(MAKE-SVSTEH SYSTEM- WW frRfiST OPTIONS) 

SYSTEM- MAMl Specifies, a system prevmusty modeled with DEF SYSTEM. 

Of r f MS Specifics options like prim the imnsfimmtJivnS thai mwftf bt doftf but don r t do them and so 

Ebiili. 

ITic construction dependency graph specified by ihc transformations and pre-conditions, in the 
Dlil'SY&TEiM description of SYSTEM- NAME is Knaty/jcd in order to determine whal constmclion necdt to be 
dime. Bach tjansformadrm is applied by first applying any tranironrialions tefero need as pre-conditions, and 
ihcn updating die Input module if it, or any modules listed in additional dependency lists, have hcen changed. 
Notice that the transformation applications are ordered by the pre-condition lists. 

Lite MAKE, r)FJ-3Y5TE : M uses simple Functions based on file creation dates in order in determine when a 
module shuu^d he fceiUKrniL-red. Howcv-cr^ unlike wakp, dmi-i;ysti:m allows the optional specification of 
predicates thai control when construction is done. The new predicates can replace the simple ifflH that are 
supplied with EWISVSITM. 

dj-j vt'sriiy includes a patching facility. It allows small chants to he made to a system without invoking 
the rci:i7SY5ri:M transfomiaiionydc^deficy mechanism, Each set of changes is stoned in a patch file that 
typically curtains lie*' Function definitions or Tedcfmitions of old functions. Each patch is assigned a number. 
If a system contains patches. then tire, patches are loaded, in uidei. allur the unpatched version of the system is 
loaded- 



An Fx tended Exempt - LINT 

Ine MiFSYsniM description for a. Lisp implementation of LfNT Is presented in figure 2-6. Although the 
Dei-system description is. easier to understand than the correspemdine MafccFile (figure 2-4). it is still difficult 
10 understand, 

The ;BUILI>-L INT-L IBRARV transfnrmacinn is assumed to have been defined and has the form: 

(^BUILQ-LIHT-LIBRARV. INPUT PRE-CONDITIONS) 

It constructs LINT library flks from LINT library sources. The transformation allows the optional specification 
Of pre-conditkjns, and is applied if either INPUT, or the first pass nf ] JNT is updatssd. 

"I he first Veyword form in Ihe 1INT DtFSYSiTTiM description specifies a. system-wide default directory. The 
next block of keyword forms declare the various modules ^riich comprise ]JNT. Ine final block of forms 
declare the transformations Used to construct LINT. Notke that as transformations are nested and prc- 
cundLtioris are added N die transformation declarations. become increasingly difficult to understand. 

Deficiencies 

Phrased in twins of construction, Lite MUKF, FH-FSYSTFM is a construction directive based tool. This is 
the primary reason th.ni ni-niVSTEM descriptions, although easier to understand dlan rVtakeFiles. ate still 
awkward. 

One reason mat DI-TTOfST™ descriptions are easier to understand than MakcFiles is because UFE^YSTEM 
is not purely construction directive based. ni-l-'SYSTJ-M's ; NODULE, declarations allow for the logical grouping 
of grains Into higher leiHJl modules. This grouping abstract away from low level construction information, 
arid provides a more natural way for user* to describe systems than maki: dties. 

ISFfSYSTPM supports (he sharing of common construction patterns through tho declaration of 



(DEFSYSTEM t HIT 

f : PAT HNAHE- DC FAULT " /US-K/SRC /I. IB/MI P" ) 

(■MODULE DEf iJlIHOHS-i fMACDEFS" "MANIfEST" "MriLEl" n LHANIFEST' ) ) 

(;M0()UIE DFFIMIIIDNS-2 ("HA.NIFE5T n "LHANIF EST")) 

(: MODULE PARSER "CGRAH") 

(zHODULE PASSl ("ACEFS" "SCAN" -lDMMI" "PFTN" "TFIEES" "QPTIM" 

"LINT" "HASH")) 
(: MODULE PASS 2 ("LPASS?" '"HASH")} 
(:MODULE DRIVER "SHELL") 

(:MDDULt LIBRARIES (*LLIB-PORT H "LLIE-LC" "LL1&-LM" ■'I.LiB-LMP h 

H LLIB-LCUfi5E5")) 

(:fASL0.6D Dl UNIT IONS" 1) 

(:FASL0AD DE F1NITIQW5-2) 

(:CDMP1LE-L0AD DRIVER) 

{:CQMPILE-LOAD-]HU PASSl (DEFINITIONS-1 ) (:rA5L0AD BE FlNH IONS- 1 ) ) 

(:COM.PlLE-LQflD-IN]T PAS52 (DEFINITIONS-?) (:FASLOA£l DEFI NITIOH5-Z ) ) 

(:COHPlLE-LOflO-IH[r ( ; LlSP-'YACC PARSER) fDEF IMIT10NS- 1 ) 

(jFASLOAD DEFEM1T1DNS-I}) 
(;&JILO-LINT-LIBRAFIY LIBRARIES {;FASLOAD DRIVER PARSER PASSl))) 

Figure 2-6; UFl^VSTrM [JcscnpEnm Fuf LENT 

transformations, This malees DFI^YSTFJU system descnpLtodi easier to produce and understand than 
MakeKlles, Hnwe>«T. since it k pmsihlc to avoid die declaration Of a complex transformation by using nested 
transformations. ra-J'svsnEM still allows for common patterns, to be repeated instead of shared. 

Vci undcrlyinu task descriptions. Although nu-SYfjrtiM has embedded knowledge about Lisp ; :mipila;ion 
and loading it does not include a mechanism -tor describing construction tasls and therefore cannot he 
extended without great difficulty, 

Intermediate trains; are referenced, CH-^YSfEKM does not differentiate between source, intermediate, and 
goal grains. ]n general, in'jerrricdiato grains arc hidden by cnmpJc* tiansformatnins. Fur enainplc. there are 
no rcFcncnccs to intermediate grains in figures 2-5 and 2-6. While dei Yrsnoi does not force intermediate 
grains to be included, it does not prohibit them cither. 

All source grains need not he referenced, In a Lisp environment, nothing can he used before it is loaded. 
This means that any grain that participates in a Lisp system will he involved in some construction, and 
therefore, it is not as natural tn omit a source grain from a DEl^YSTFM description as ]t :s to omit one from a 
MakcFilc. This difference between make and DCFSY5TEM comes from differences between the UNIX and 
J .tsp environments, and not from important dilTercrjtes between the two tools. 

2J Other Took 

UcRemer and Kron introduced the lerms programming- 1 n-the-large and pn.^nninrng-in-Ehe-small 
[IX'Rcmcr and Kron 76) to distinguish hetwecn the writing of modules and the structuring of modules into 
systems. Consistent construe Lion is just (me prL$rammJng*m-lhe'farEC Ksoc. others include source cude 
management, module intcrennncctiun sped rjcaiirtfi. and version control, A oriel" summary of these other 
issues and pnsjccls that futus upon Lhcrri is presented here ha completeness. Ihe consistent construction 
components of these projects do not differ from makl- : ornfiFSYSiriM in any significant v-ay. 

When several people are working on a system simultaneously. It is Important to regulate access to the 
Source Code modules- in order to cnsuic tiiat someone dues not attempt 10 modify a module while someone 
else is modifying that same module. A common scheme is to implement a Ubmrtsu (hut regulates access to 
system components via a chcck-in/chcck-uul mechanism, In Short, only one person js allowed to chccK-Oul a 
module for update at any time. Anyone can rend a module at any time. Source code management systems 
are descniicd in die RiHowLngpa[WI%|RtiCllkiHd 75, CrBiolof. eLai. tHl. JkHS&ej and I .parti 7U, [.(jwislllj, 



AN of the problems mentioned above arc compounded if the programminE cnviiimmcm is distributed 
over a ncc^orfe, Schmidt addresses ihcsc issws [Schmidt *2l 

El ii Dfte-11 the CHS? th-JH [here arc families of ■syslemK being, maniigcd. t ,l nr example IhcFe may he several 
pub]k releases of a system,, internal releasee, cipcnmcnlat vCrsums. fund ki on. !l is ahin common for there to 
be several versions Of a system intended to run «n different hardware ronlitju rations. I'Jicb memoer of a. 
family of software systems usually shares miinj 1 cnmpuneuli with uthCr members uf the family. .MiiintaitlerS 
of SWCh families need tn worry uhuiJl vytiieh versions of ■whieh mttduteSiirc used in eaeh member of [he family. 
I'ich]; and Coopnder atliiL-ked UlC piublems associated with rJl-G representation and iliiinagjCmCiU of software 
families [Cuoprid« 79, Tithy flfl, Tirhy 84]. 



3. The BUILD Reference Level 

"Ihis chapter introduces Bt'tt.b's reference based syslem modeling scheme. aim.n system models- art very 
ea>y '.o interpret because |hry -Cdntiiiil nulling more than declarations of how grains are grouped 10 farm 
modules and how these modules refer to each other. Although they do rwi present any construction 
dependencies explicit they can be used to derive all of the construction information found in construction 
bused models (see Chapter 5). Construction models, cannot be used to derive the reference information (bund 
irt re fare ni:c mucins, licicrencc models are far less Confusing than the construction based models because 
they are written in a language that replaces low tcrill gram construction information With higher level inter- 
mudule reference paUcms. 

3.1 Modules 

][ lS often (he case that groups oF grains are conceived as One logical entity but are Split Up (e.g. into files) 
for other reasons. Modeling schemes that represent sy-sscms only at the Level nf the individual £iiiin dunot 
have the ability to csprcss dns kind of grouping, "(he module construct used by reuini (and DErSYSreM) 
allows these groupings to be made CaplicLdy ]n system deicriptions- 

umi.U module declarations have the form: 

(r NODULE MODULE- HAHE GRATM-TVPE &REST GfiflJWS) 

MOGUL E - MME The rjamc of a module, The name must be unique wl Lhin the system model, 

GRAIM-TYPE The name of a grain type recognized by nt;ri.D. Each grain is assumed to he an instance of 
mistype. 

GRAINS TJie names of the grains that comprise the module. 

The following fonn declares [tint MAIN is ii Lrip Suurec module- composed of the single grain MAIN . LISP, 
(iMgrjULL MAIN rLTSP-SOUfiCE "MA.J »1 ISP" ) 

and the form; 

(:MODUL€ DEFS :C-S0U&CE "DEF INI TIQN5- 1 .C* "DEF IN] TIOMS-f .C" ) 
declares that QEFS is a C souice module with two grains named DEFINITION 5- I^C and. 

OEfimmoNS-2-c. 

build can use grain type infoimatmri without considering module references m determine a great deal 
ahcwi the construction of grains. For instance, wjittjn knows how to invoke the- correct compiler on C or Lisp 
Snurcc files or how (o const ruci u>T library flics from library sources by utilizing grain type information 
iilunc 

3,2 Kt' Terences 

ISLlJl.lj infers construction dependencies from reference assertions by tating advantage of the fuel dial 
construction dependencies are caused by references between modules, Ifiwu modules do not refer to each 
other, then it is impossible fur there to he a construction dependency mat involves them, When the assertion 
is made that fwdufc i refers, ro module r nurtj) pessimistically assumes that each grain to mfxiule refers to each 
grain in module 

References with the same name may be handled differently depending upon the grain types, of the 
modules involved in the reference. For instance, the cath reference between two Lisp source modules is 
handled dirTereiuly dian the CLzMjrelercncc hetween two C source modules. 



mill 13 rclerence declarations pnu ide lor the spCL-ilicatiofl Of references, between modules. No meaning is. 
attached en the ordering of reference decLuatioiis. Reference dcelii rations have tine form: 

(RCFEBEHCi LEFT-ELEHEMT RIGHT -ELEHEtlT) 

ff£ FEPENCE ' I he name of a ft fci encc * ccu^n/ed by muii .n. 

LtFT-Ei FMEtvT A module n,imO or list s»f module names. All module names used in a reference 
declaration must have been declared in a module declaration. 

fflGHr-ELEWtfVT 

A module name or list c»f module names. All module names used in a reference 
declaration must have been decljrcd in a module doclariltion . 

['he use of module name HsiS as Cilhcr Of the ekmcnlH (*r™ reference declaration is Syntactic Sugar U! Lit & 
equivalent tu the set of reference declarations, enm posed by enumerating REFE REHCE -mam£ with each pair 
in thecniss product of" the rifht and, IcFt element lists. For comple: 
(: CALLS (A Et) (D E>) 



B 


equivalent to: 








(:CALLS 


A 


11) 




f ;CALLS 


A 


f) 




f lCALLS 


B 


D) 




(iCALLS 


Fi 


El 



Hen: are some reference triples and the construction dependencies thai they imply: 

{:CAllS LISP- SOURCE -1 LISP- SOURCE -2) 
Asserts that LI5P-50URCE-1 contains functions thai call LISP-SOURCE -2 and implies that 
L jsp -SOURCE-? will need uo be ioaded in order for l ISP 'SOURCE -l m execute. 

(; MAC HO- CALLS LI SP-SOURCE- 1 LI5P-SOURCE-2) 
Asserts that L I SP-SOURCE -1 uses rr^ros defined in LI SP-SOURCE-? and therefore LI SP -SOURCE -2 
must be loaded in order for LISP -SOURCE-! to compile properly, J his reference implies that if 
LISP-SOUHCE-2 changes, then L I SP -SOURCE -1 wilj need In be re-eompilcd. 

(:£ALL5 C-SOU*Cf-i C-SOURCE-2) 
Implies that (he object grains compiled from C-SflURCC -Z {as well as the objoa grains from any module 
that C- SOURCE -2 calls) need to be linked Into any executable image that is en include the object grains 
from C -SOU RCE-1. 

(: INCLUDES C-SOURCE-1 C- SOURCES) 
Asserts trial C-SOURCE-1 contains the contents of C-SDURCE-Z; This Fefcreiice implies that whenever 
the inctuded modiiEc, C - SQURC E - 2, changes, the Including module. C ■ SOURC E - 1 , needs, to be rehuilL 

BLitt.il uses triples tolled reference signatures J of the doom 

<RFFFRE tiCE -NAME L EF T-GRAIN -TYPE- NAME fflfirfT - CM IH' TYPF - MAME > 
10 identify references. RLIl.D uses, grain type information (0 distinguish hclwccn references IhaL have the 
same name taut iippl^ in dilferem grain types, A given implementation oF It I II. n will define the reference 
signatures that itc comiiumJy- used in the environment that itt.ni ti ii working, with. Chapter 5 describes how 
new reference signatures may he added to nc:n.t>. 



3.3 Models 

'Ilk- gciwral fonn of a itUli n system description is: 

(DEFMODEL MOOFL-IVAMf SRE5T DECLARATIONS) 

'ITicrc are ftiur tinds, nf ttecbriiLions tti^H m.iy he included ifl a BEfMOOEL fonn: mudulc, reference, 
cicfujult pathname, iind dtl'iulL module. Module iind reference declJinitiitftt WCFc described earlier in this 
chaplcr. 'The defiiull pathname declaration aJlowv for the decuinatiLin nl a pitihnumc to of used u> a template 
for completing liknuiiiKv ][ has die formi 

( r E F AUL T - P At HNAKE PA TMtAttE ) 

'Ihc default module declaration is incd (D dectare a module ms the default module for nunc to operate on 
when construction requests far Lhe system arc made. Ic has 1he form: 

(: DEFAULT -MODULE HODULE-NAHE) 

Figure 1-J cunlains Ihc DEFWODEL form lor TlNYCOMp, 'The first fuur declarations are- module 
declarations that specify tile grains and criun types nf the system mndulcs. The Lasi three declarations Specify 
the references between the rrkjdules in die system. Kigurc 3-2 contain* the Dif MODEL form fur i.tw r. 'Ihc 
mudei is longer Uhuii uw ihmyctqmi' model but no more complicated. 

: in- = m.:dh iiNri:i:HP 

(: MODULE BEFS :C-SOiJfiCE "BEF I H IT 10*15') 
(;MDDULE PARSER : VACC-GRAMMAR "PARSER"} 
{:MDDULE CODE-GENERATOR :C-S0UftCC " COOL GE H - ) 
(: MODULE LIBRARY ;C-0BJECT "LIBRAR¥ rt ) 

{^INCLUDES (PARSER CODE -GENERATOR) 0EF5) 
(rCALLS PAFlSfH f I IHHAHT CODE -GE NEF ATOR ) } 
( [CALLS CODE -GEN ERA TOR LIBRARY)} 



{DEF 



Figure 5- 1 ; bUl LD Mod*l For unycomp 

MODEL LINT 

DC F All L T - PAT HHANE " /USR/SRC /LIB/MIP") 

MODULE DEFIN It I0W5-1 ;C- SOURCE 

MACDEFS" "MANIFEST" "HFlLfl" "LMAAtF EST" ) 



MODULE 


DEFINITJOHS-2 3C-SOURCE "MANIFEST" 


"LMANIFEST") 


MODULE 


PAfiSER 


iGftAMHAR -CCRAM 11 ) 






MODULE 


PASS-1 


;C-SOURCE "LIKT") 






H0DU1 1 


PASS-Z 


rC-50URCE "LPAS5Z") 






HDDJLE 


SUPPORT 


-1 :C -SOURCE 






KDEFS" 


'5CAW 


"COWil" -PFTH" -TREES" 


"OPT III '-'■■.'■;!• ■ : 


MODOE.E 


SIJRP0H1 


-3 :C-S0URCE "MASK") 






MODI. 1 E 


DRIVER 


■SHELL-SCR1PI "SHELlM 






NODULE 


LIBRARIES rLIHT-lIBRARY-SOBRCE 






LLIB-PQfiT* "LLIt-LC* "ILIB-LM" "LLIB- 


LHP" 


"LLIfl-LCURSES 



: IHC LUCES PASS-1 DEF1 N IT ION5-1) 
: INCLUDES PASS-? tit MN) I ]QN5-2) 
:CALLS DRIVER {PASS-1 PASS-2 LIBRARIES)) 

CALLS PASS-1 (PARSER 5UPP0RT-1)) 

CALLS PASS-2 5UPPDPJ-2)} 

Haurt >2: huii.l> Inscription For rjNT 



4 The BUILD Task Level 

"litis chapter describes die lask level rcpreseiUdiion of systems used b>- m-ll.ll, A Utilf level incidel i* 
derived from the rellcrencc te*el model flu cadi request ih;n mill " receives. The derived model H then used 
lo biindk the request. {The phrase kak level is used in place (tflhc more-sped fie phrase wmtmvtiw fcrri 
1)eeauSC injltn is used M.n lTHHeUinnjuslanisLruclioii.il 

IHJtLh Ltsk keel models me atyclic directed grjphs with Lwn k i nds of nudes: g-utxies which represent 
grains, and p-wtwte which represent die processes used to construct grains, ] ^af nudes represent source 
Brains, ;wd rittA nodes represent goal grains, TJ»e link between grains and the processes Ulat use Uiem in 
modeled by linkine, Uie p nodes rcpreymunig grains to Use p-nudes representing the processes that use diem. 

Figure 4-L EDDftniJiK n portion of the U«sk Jimph used LO rt-prcsenL the CLimpilaLk>n of PARSER. LISP, a 
Stain from u l.isp implemcnlatJmi ofTINYCCIMK Ill is example a<Siim« [hut PARSER , LISP is a source grain 
and tgjtons the fail UtuL in uKrroMP, PARSER , LISP is an intermediate module pntdsKcd by L ISP- fACC. 
[he ellipses represent g-nodes and die rectangles represent p-nodes. There are twu source nodes. 
PARSE R . L I SP and BE FS . LISP, and a Si ngtc goal node. PARS E R , IMAGE. 

Although the use of jin acyclic directed graph to represent List processing h mil unique {mam: and 
DWSysrSM use similar representations) the derivation of Last (.ruphd; fnmt reference mudcls is novel, 




Figure i- {• Simple Task G raph 



4.1 Grain lypes 

Grain type objects are used to represent the classes of grains used by the environment chat build is 
workiftfl With, They are used to represent all nf [he kinds of grain* thai are manipulated by the underlying 
environment, wheiher they are files or not, For instance, die grain type i LISP- IMAGE is used to represent 

the eibjects that result From loading files, into the LtSp environment. 



Bcli ninjj Grain Types 

drain types arc defined *ilh BEf INE-GRAIN-TYPE and definitions have die fornr 

(DEFINE-GfiAlJJ-TVPE NAttf SOPTIQNAL FILENAME-EXTEHSION) 
NAME 'i he name (tithe grid n type hems defi ncd , 



FILEmttf-tXTEUSIQU 

'["he dciaull filename extension fur grains of this type. If this field is null then blii.e> 
assumes that grains of this tyiKi arc not files. 



l-'ljmirc 4-2 fnnijiins the grain Jvpe ddlrti Linns used 10 omctel lisp systems, 'Ihc : LISP- SOURCE and 
:LlSP-BIMART groin types correspond Lo files and hence Lhcir dcilni lions include delimit filename 
eaicnsiuns (the I .isp Machine uses keyword symbols lo represent filename extensions^ 'Ihc : L ISP -I MACE 
f:"iiin i_vpe is not ossjjEijted with files and therefore has no default filename extension. 

(DEFIHE-GfiAjM-Tm :L ISP- SOURCE :LISP) 
f&EFIME-GnAIM-TrPE :L ISP-BTNARY :BIH) 

fDEElHE-ORAIW-TYPE :LI5P-1HAGEJ 

HgUfP J-i Grjiin Type Definitions for Lisp 

4.2 G- nodes 

O-nndcs represent gniins in task graphs, they contain the Following information: 
ttAME "ITic name of the grain represented by this g- node. 

TYPE "[tic grain type object (hat the grain represented by thisg-nodc is m instance of 

WDOULE Optional. J he module that includes the grain represented by this g-nodc. 

•'■'.'-"■ ' ! ',"■' Optional. 'I Tie p-node that represents the process that created this g-node. This field will 

be null if the g-nudc represents a source grain. 

USERS A lislofp-nodes that depend on thts g-nodc tn fiEl an input toLc. 

JWtflfDIfwrs ^ list chat represent the source grains used to ptoduce this g-node. Each element of die 
list is a pair containing the name jnd creation -date nf an ingredient gTflin. 

CRE ATE -DATE A time Stamp that represcols ihc dme and dale when Ihc grain thai is represented by this 
g-node was created. 

4.3 Protest Types 

Process type objects, contain the informatton pertaining to classes of process instances (represented by 
p-nodes}- For example, the Lisp Machine implementation of Bt.Tl.D includes process type objects for Lisp 
compilation and l.isp binary hie loading. 

The grains that are used and produced by processes are partitioned, according to trie rotes that they play in 
diem. Grains, that processes use are said to play input roles. Grains that arc produced by processes are said tu 
play output wits. 

Process (ype ohjects contain role descriptions for each of their input and output roles. Role descriptions 
contain the following information: 

NAME LTic name of the role. It must be unique within the process type being defined. 

GtiATIl-TVp£ The grain type name that grains filling this role musthave- 

ARITY liilhcr SINGLE or : MULTIPLE. A role with arily : SINGLE can have no more than one 

grain filling it. A role will) arity r MULTIPLE can have fin arbitrary number of grains 
lilting it. 

NAM£ -SOURCE Optiu-n.il. "["he name of a role used to help derive names for grnins (hut will fill this role. 



Mo lining frocess. Types 

I "i tjce>.s. types H re defined * ilfo DE F I N t - P ROC ESS -TYPE and culls have the Form : 

(DE FINE -PROCESS- TYPE flAW INPUT-SPEC OUTPUT- .SPEC STREAM-MR 

iVAMF Ihcnamc of ihcpniccss type. 

INPUT- SPEC A h'sLuf input role descriptions (discussed abovcL 

OUTPUT -SPEC A, list ofoulpjjt riite descriptions, 

STREAM-VAR \ var\abk: name that will be bound to die output dream when DESCRIBE -FORK and 
COWS TfiUC r - f 0flr*S an; evaluated. 

DESCRIBE-FORft 

A ftirm [n be evaluated in order to describe die processing represented by an instance at 
this process type. When the farm is evaluated, each, rnlcnamc will be hound to die names 
of the grains playing the nitc. AIbo. the symbol named by STREAM- VAft will he bound to 
Ihc output stream. 

CONSTRUCT -FORMS 

The forms to be evaluated in order to accomplish the processing represented bjr am instance 
of the process type, When thev: forms arc evaluated each of ihc role^namcs and the 
symbol named by STREAM-VAR will be bound, as mentioned above. 

Figure 4-) contains the process type definitions for Lisp compilation and Lisp binary loading. The 
definition for : LISP -COMPILE sped Fira that dicre arctwn Input roles, SOURCE and DEFINITIONS, and a 
single output riile, BINARY. SOURCE has singular arily and must be filled by a :LI 5P-SQURCE grain. 
DEFINITIONS has multiple arily and can only be filled by i LISP -I MAGE grains. BINARt has singular 
anty and must be filled by a : LISP -BINARY grain. The describe form produces descriptions like: 

"COMPILE PARSER. LISP" 

Ihc enm-truct forms produce die grain playing the BI N ARlf rule by curripjling the groin playing the SOURCE 
role. The construct forms also cause a notification of the compilation to be sent to the output stream. The 
notification looks lite: 

"COMPILING PARSER, LISP,** 

Processes often depend on grains not explicitly mentioned in theii invocations. For example, in languages 
that rely on objects to be specified or loaded before objects that refer to (hem can be compiled, the 
compilation PR^CS type must include a note diat is used to capture di.it dependency. The rule 
OFF I NIT IONS »S trad in : L ISP-C0MP1 LE in order tn ciprcss the need for snmc things to be defined 
before a Lisp grain can be compiled. Ihc link, between the g-nnde fur DEFS. IMAGE and Ihc p-ruidc 
representing the cumpilation of PARSER. LISP in Che La^k model from figure 4-1 is an example of such it 
dependency being modeled. Another situation in which it is necessary tu model a dependency not made 
explicitly in command line invocation is for C compilation, ITrre ;C-CGMpIle process type has the robe 
INCLUDE CO represenl the dependency between a file and the files that it includes via the C #INCLUDI 
mechanism. 



(OIF m£ -PHOCFSS-TTPE rUSP-COMPlLE 
{{SOURCE :USP-SQUffiCF. 'SINGLE) 

(DLf JNHIONS :LISP-1HAGE ^MULTIPLE}) 
{(BINARY :L1SP-BINARY iSINGLE SOURCE)) 
OUT PUT -ST RE AM 
{FORMAT OUT PUT -STREAM "-^COMPILE -A" 

(FORMAT DJTPUT -STREAM "-&COMP I L [NJG -A" SOURCE) 
(COMPILEFt;COMPlLE-FlLE SOURCE BINARY)} 



^SOURCE INPUT ROLE 
■DEFINITIONS INPUT ROLE 
■BINARY DJTPUT ROLE 
;$lii-UM-VAR 
:DE SCRIBE-FORK 



;CONSTRUCT-FOfiMS 



< lit MNE -PROCESS-TYPE rLlSP-LOAD-BIM 

((BINARY tLISP-IINARY SINGLE) 

(DEFICIT 10*15 :IISP-1HAGE MULTIPLE ) ) 
({IMAGE :LI$P-IMA&f :S]HGlE BINARY)} 
OUTPUT-STREAM 
(FORMAT DDT PUT -STREAM "-ItlOAa -A H 

(PAlHWAMF-MINUS-VEflSTON BINARY)') 
(FORMAT OUTPUT-STREAM "-'KLEIAUING ~A~ BINARY) 
(SI:LOAD-filNARY-riLE BINARY NIL T)} 



;HIVW IM-UI flCLE 
^DEFINITIONS INPUT 

i IMAGE OUTPUT ROLE 

;STREAH-VAR 

jDESCRlBE-TORM 



ROLE 



;CQNSTRUCT-rQRH5 



I'tgure 4$: J'rOWSS. Type I Jefnition* Kor ] .isp 



4.4 P* Nudes 

Each p-node represents* princess tn he invnfced on the grains auached io its input ports tn produce the 
grains attached to its oucpm ports. Each. rn]c in a process type is represented ss * port in p- nodes of that type. 
The aniin *ypc ert'each £-n«dc attached m a pan must be the same as the gjain type asKHriatcd with the role. 
A. description o/ the proteasing. represented by a p-node 3nd the g-nndes aLLoch.ed to its. ports L-.M be produced 
by applying DfSCftJfff-FORN from the p-node'-s process type object to the p-node, The processing 
represented by the p-node can be done by applying. COflSTRUCt -FORMS (ram die p- node's process type 
object to tiie p-node- 

T-'igHTT! 4-4 conLaiire an expanded view of [be p-node used to represent the compilation of PA RSE R , L IS P 
inTTNYCOMP. 



CDErs..i«*Gi J}- 




PEF[NITIOU 



HurCe 



LIEP COMPILI 



RIWAHT 




Hpinc 4-4: 1 ■Apbifidcd! P- Node 



4.5 [ask Graph Constraints 

I ask graphs are amstraincd in the Minting ways: 

1, Tails graphs arc acyclic. A cycle in a graph would imply lhar sinnc grain was needed ill order to 
CLHislmcl itself. 

2. ' I Tie parent of a g- node, if there is- one, must be a p-mudc. 

J. A g-node tan have mi more than one parent 

4. A g-nodc without & parent represents a source grain, 

5. The children nf a Eyerie, if there arc any. must be p-nnclcs. These nettles represent processes that 
depend upun the grain represented hy the g-nodc. 

6. A g-iusdc without children represents a goal grain. 

7. The children of a p-ncide must he g- nodes. Ihcsc g-nndcx represent grains derived hy the process 
represented by the p-node. l-jch p-nnde must have at least one child, 

fn other wu*di. task graphs are acyclic graphs which begin with g- nudes that represent source grains and end 
with g" nodes that rep resent goal grains. 'I he g- nodes are separated hy p-nodes that represent the processes 
(hit derive later g-riodcs (mm earlier ones. 

Figures 1-2, 2-1. and 4-1 arc examples of well formed Laik graphs. 

4.6 live Construct ion Algorithm 

Figure 4^ contains the algorithm used by PUll..r> to perform the construction modeled hy a task graph. 
This algorithm is similar en {he one used hy MaKII and DFE^iYSr™ (figure 2-3>, the primary difference 
hetween the two algorithms is in hu 1 * they make use of citation dates to deierrrjant when Lonstrucuon ifi 
necessary. The maku algorithm uses file creation date ordering between input and output grains in order to 
Infer thai an input has changed (and therefore construction b triggered). In practice this method, worts, 
however, it relies on several assumptions that arc nor. necessarily true. 

MAKF and rH : .T-'SYSTFM assume that flics with the same name hut different extensions are related. For 
instancc, they assume thaL MAIN.ii was. crCaLed hy compiling MAIN.C. While this is a reasunahk 
assumption, it does not have to be tiue. Nulhjng prevents users from. renaming file* ant! there flue, there is no 
guarantee diat MA I H . actual ly came from HA 1 N . C. 

[fan output grain contains a Tile creation date that is newer than all of the input grains used to produce iu 
frtcn M/kKI 1 . and nn^VJTFM assume that the output, grain docs not need tn he rebuilt. However, there is no 
guarantee that file creation dales have not heen tampered with. 

EElJEt.D docs not use file creation date ordering to infer that an object tias- changed. BUILD compares a 
grain's Lngtedsent lilt with the ingredient list thai would result if the processing modeled by the List graph 
were done. If the ingredient lists ntauht, then the construction is not done, 

The prototype implementation of mjeeh keeps a separate data fite that contains grain creation dates and 
ingredients. Such a file would not be needed if the underlying environment recorded the ingredients used to 
produce an object, 'lite Mesa environment [Mitchell 79, Schmidl %2] keeps this information and exploits it in 
order to determine when processing needs H> be done. 



(DEFU« CQNSTHUCT-G-NDDE (G-NDDE) 
(CDND ((SOURCE-NODE-P G-NODC) T) 

((OH (NON-EXISTENT G-NOOE } (INGREDIENTS-CHANGFD G-NOOE}) 
(HftfCAli *" CONST RLtCT-G- NODE ( INPUTS (PARENT G-HODE))} 
(DO-CONSTRUCTION (PARENT G-NQDE))))) 

(DEFUN INGREDIENT S-CKftNGFO (n-NOnf) 
(NOT (EQUAL (INGREDIENTS C-HQDE ) 

(DERIVE-IHGREDIENTS G-NODE}))) 

(OEFON SOURCE -MODE -I 1 {G-NOOE} 

;: RETURN5 T IF AND ONLY IF G-NODE 
l> REPRESENTS A SOURCt GRAIN 

J 

(DEFUN NON-EXISTENT {G-NODE ) 

;; RETURNS T IF THE GRAIN REPRESENTED t§r G-NQUF 

;; OOFS NOT EXIST 

) 

{DEFLjN PARENT (G-NDDE) 

;; RETURN THE PARENT P-NDDE OF G-NODE 
> 

(DEFUN IBPUTS (P-NODE) 

:; RETURN THE INPUT G-NOOES OF P-NODE 
) 

(DEFUN DD- CONST RUCTION (P-NODE) 

■; PERFORM CONSTRUCTION REPRESENTED BY P-NODE 

) 

(DEFUN INGREDIENTS (G-NODE) 

;; RETURN THE INGREDIENT LIST USED TO CONSTRUCT 

;; THE EXISTING VERSION OF G-NODE 

) 

(OIFLJH DEHIVE-IhlGREDIENTS (G-NQDE) 

!l RETURN THE INGREDIENT LIST THAT WOULD RESULT IF 

;; A NtW VtftSlON OF G-NOOE WIPE CONSTRUCTED 

) 

fr'ifiure 4-5: noi.D Construction Algorithm 



5. Construction Requests and Task Graph Derivation 

AflOT a System has hcen nuwielcd with OEfNODLL, null n can be wiled ur>m to handle ciuiMniclion 
Inquests fisr iL. Hath request hits Lhc form: 

(BUILD- REQUEST MODEL REQUEST S0PTIQHAL HQ-DULE (MODf ; NORMAL)} 
WDDFJ. "Ihc name of 4 rtHjdcl previously defined wil h PE F MQOE L , 

RE QUE $ T The name of a request recojjn ized hy nt: 1 1 .r> {e.g ; COMP J L E . : LOAD). 

MODULE lhc iumc uf a moduk tu up* raw upon. If this field is not specified Itttn the default 

module for the system Cas defined with the : DE FALL I -MODULE docrafiitiun form) is used. 

MDOF Specifics iHtt of several construction modes. Construction modes iiir discussed twluw, 

'lhc prototype Implementation of AtHID has three construction modes that bcltflMC as fbllowSJ 

iMQRHAL lX-scribc all of the construction to he done, arid then ask the user iF nun. I J should perform 

the uorlstfueEn.ui jusL descrihed. 

: DESCRIBE I describe all of UK Construction Ui be done hut dn not perform It. 

;hO~ COM FIRM Perform the required construction without describing it fiftt. 
Sample rjt.rn.rj requests are: 

(BUILD-REQUEST TIHY-CQHP. ;LQAQ) 
(BUILD-REQUEST LINT [LOAD DRIVER) 
(BUILD-REQUEST LINT rLQAD 1 DRIVER iDESCRIBE) 

Once a request has been received, a urn-*: step proees* \\ excevncd for each, grain in the module stated in 
the- request. Ih is. process creates a task model for (he request which is then processed Ln Ute maimer outlined 
in chapter 4. The three steps are: 

".. Model the construction that tan he deduced from, the request without COnSidtnng any rcfcrcnccs. 
This phase is £$]]$& pft-tlfcrcnce rcqucsi processing. 

2, Model the construction that is Implied by the references that involve the mndulc associated with 
the request. Tint phase is called tfftrencf prvecsttng. 

3. Model lhc construction that can he deduced from the request and the graph buill from the earlier 
steps. Ihis phase is called twit- reference rrqucsfp.Tixessi.rig. 

After die pust- reference processing has Ixen completed the- last ^raph is complete and can be used to direct 
the CtmstrueuuTl needed to hmdlc me request 

Before the construction process can he explained in detail it is necessary to present the functions used to 
view and manipulate task graphs. 



5J Viewing and Manipulating Task Graphs ■ ACCESS 

Conuder die u.Mlkniiin£ Ui^t graph: 






SOURCE BJHAKlf 

■IISP-CdMHLE 



-s^ifS-.'fliiO-J 



IIIHAHY H1>1.jI 

: LI 5P" LOAD-BIN 



Mttrting j[ j p-mide, (he p:hLh Gn any of ihc £-nodcs connected lo One uf its pMias can he specified by 
men Lion nig die Mine of 1hc port dcHLred. I it UlC task RF.nph abtrve, starting jl die i L I S P - COUP I It p-nndc, 
the sfepEI N&.RT leads to DE FS . Bl N. 

A SKfi friim j £-m.ide a? j p-llude can be described by specifying (he process type of the connected p-mulc 
nnd the role played by (he &-ru>de in Ihc p-ntKkr hi dm Sample task graph above, Ihc Mep (BINftKY 
: USP -COMPILE) SEurtiflg m DLFS . Bl N 1c:h3s Hj Uil* :LISP- COMPILE p-nodc. 

i'atlu are funned by listing steps: 

* Ihc path ({SOURCE ; L ISP-COUP Hi} BINARY) guning, a! DfFS.LISP (cads Kh 
DEF5.BIH, 

* The path ((SOURCE :LI5P-C0HPILE) BINARY (BINARY l LIS P- L0AD-BIM )) Starting 
AtDEFS.LISPleadiW the ; LlSV-I.OAD-BIN pnnde. 

* The pain 

((SOURCE :LISP-COHPILE) BIMJAHY" (BlKAFnr :LlSP-LOAQ) IMAGE) 
Starting at DEFS. LISP Leads Lu DC FS . Ifc AGE. 

" ]"he path 
({IMAGE :LlSP-l.OAft) BINARY (BINARY z LlSP-CGttP ILE ) SOURCE) 
Slartrafc at DEFS. IMAGE leads to DEF5. LISP. 

The ACCESS family of functions are designed tn- provide a straightforward mechanism for bath viewing 
and manipuLaLing »sk graphs- These funcLiniiH are used heavily during ihc task graph derivation piowss. 
Then.- art three (unctions, ACCESS, ACCESS+. and ACCESS*, each of which is SETFable. The ACCESS 
functions have (he form: 

(FUNCTION HODE PATH) 

FVtlCTIQH ACCESS, ACCLtSS+^er ACCESS*. 



KQOE 



Either a p-nodc or a. g-nodc. This nude is used as the root nf the padi to be traced by 
ACCESS-FUNCTION. 



PA TH A list uf soeps to be traced frum NOOE. 

Hie functions' behave in the ftrfluwi ng manner: 

ACCESS Tr;ices PATtf ftum NOflF and returns ihc last node encountered. An emir K signalled iF 

arty stop in PATH cannut he traced. An error is signalled if there cuuld be moio thim one 
(Hide thai sialisficH die padi tfated. 



ACCESS* IViiecx PATH from NODF and rcLtinis n liisL of m«fcs thai biiinfy the palh. An error is 

signalled if amy step in PATH cannot be traced. 

ACCESS* Traces. PATH fioin rVQDE and returns the single nixie that KiiLiS-flcS Lhi pa*h. An error is 

signalled if thtTe cuuld be mine uian one node lh.ii HuttslKS PA TH. New nodes are created 
if steps in PflTH du ndt exist. 

Any ACCESS call Ohut rcuirn&a single node may ho used iu specify ihc root uf another cal I to ACCESS, in 

other words. Lhc fiHlu*ing [w^calls arc equivalent: 

(ACCeSS NODE (STEP! SUP? SHPA)) 

(ACCESS (ACCESS (ACCESS MODE ST E P 1 ) STEP2) STEP3) 

r-iaeh of the ACCESS functions am be SET Fed. Gills have the farm: 

{SETF (ACCESS ROOT-NODE PATH) END -NODE) 
(insures Ul;il future twl Imih ACCESS wiLh ROOT -NODE and PATH 
(i.e.. (ACCESS ROOT-NODE PATH) jwill return END-NODE. 

(SETF (ACCESS+ ff 00 J -IfflfJE PATH) lYOOF-USr) 
Knsures that future calls to ACCESS* with RQQT-NQM and PAT*I 
(I.e.. (ACCE5S+ ROOT-NODE PATH)) will return NODE -LIST, 

(SETF {ACCESS- SOOT -NODE PATH) tND-NOM) 
Ensures IIwt fiiiuiL- calls 10 ACCH SS- with BOOr-NO-ftF and PATH 
(ix n { ACCE 55" HOOT - NODE PATH)) wil I return FND - NOOf . 

The ACCESS functions d iffer in ho* ihey handk steps that cannot be traced, and what j ;-.c;, tfn Ythcr. a 
path dcwripiioTi fans out, If ACCESS or ACCESS+ encounter a missing link, an. error is signalled. ACCESS* 
ar.d the SETF functions wil] create the lint and continue tracing, the pain. 

A fanoul condition occurs when an attempt it made to trace from a iKULT 1PLE artty port of a p-node, at 
when more than one p-node satisfies the nale-name/proccsH-type-name constrain? tracing from a g-nodle, 
ACCESS, ACCESS" and theJJ associated SETF functions signal errnrc if farmut k cncnumcrcd. ACCESS* 
will continue casing down all paths and, returns the list of nodes that satisfied the path description. When 
SET Fed, ACCE5S+ will signal an error if fannut is encountered before the last Step in die path description. 

Tn Lisp Machine L.iSpfvVcinjcb and Moon Si] aod Common [.ssp|Sreclc g4|. rhc- special form PUSH Can 
be used for Junctions that arc Si T Fable. PUSH can be used to add a g-nodc 1x5 a port. Fnr example: 

(PUSH SOME -r> MQOE (ACCESS* P-NOOE SOME-PATH) J 
is equivalent Id: 

(SETF (ACCESS+ P-NODE SOME-PATH) 

(COUS SOME -G- NODE (ACCESS+ P-NODE SOME- PATH) ) ) 

TtK! SETF farms and ACCESS* can. mate additive chur.ues 1o the graph. When a function needs to create 
a {-node and link it Eu a p-nodc pitft, a name needs tn he Kvniheci/e.:: rbr the new g-nodc, Ilie name of each 
g-nndc resembles a filename in that it has two pans, a primary name and an extension. In order lo synthesize 
a fl-node name, (he function copies the primary pan from the grain attached to the port specified as the 
NAME -SOURCE port for the port being Einled to J,sec the paragraph about m1e descriptions in chapter <t). Asi 
erfitf is signalled if a functiun needs to derive a g-nodc name (0 link to a port thai ha* Flo NAME^SfJtfflCF. port 
associated, with it. I he extension Of a g-nude name is derived from its grain type object, If the grain type 
represent f c--., the- die OAteir-.ur. 11 t:-c def'uull-^ilenamL-extenwi ::, otherwise, i1 is rh: r..-ivii- ;M' ihc J.i-i n 
t>pc irsclf. 



S^lkcqucsL Handlers 

Request handler specify the Uwi ^r^iph derivation slept; ch-iil cart be la "ken wherever ihe request uWHCMMd 
with (lie handler has Keen made, wiitk>u[ considering 4iik>- reference dccla ration*. Requests arc identified *ifh 
ncqucsL signatures {much like referente signatures-), Hacfct requcM signature contains (wo- Fields a request 
minic and ;i gr:iin type Hume. h'uT example dm *ii$Oaturc: 

<:CDMP1LE :LISP-SOURCE> 

idtiJCifcs (he handler designed Hi Njitd pun of the IhsI gjaph needed Hi accomplish the cnmpikLtnn of a J .isp 
source Brain, lite signature: 

^YACC ;YACC-GfiAKHAR> 

identifies the hflfKllCF dial will build part of 1hi: insk firaph needed tn invoke YAtT on a grammar. 
Niil bill possible sigJUliUTCS wi3l have handlers dc Fined for them, l-'or example t3ic request signature: 

<: COMPILE :LISP-BI HARTS 

idcniidcsii nonsensical request, 

Plre-fcfcreiicc request hiindlcrs are teed to construct the flirts of a task gftiph which *ill be needed 
rcgJiTdless of the ramifications oF references, l-'nr example, in order to model die compilation of some 
: LISP-SOURCE grain, G.LISP, the following tinti can be nude without considering any references; Che 
g-node representing. G, LISP should b* linked ui- Hie SOURCE pure of a :LlSP-tO«PILE p-node, und ihen 
the B I HA FY port of diis p'nodo should be linked to- a &-node representing die binary version ofG . LISP (Ijt, 

B.Biia 



EDUHCt fllUAfW 
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Post- reference request handlers are used for modeling processing dim can only be deduced After die 
implications nf the references are added en the Cask graph. At this lime it has not been necessary to use a post 
reference handler, however, they aie included because there may be situations where their use is appropriate. 

Defining Request Fhrtdlcfs 

Kcqucsl handler aic defined with DEFINE- REQUEST-HANDLER. Calls have the form; 

(DEFINE- REQUEST -HANDLER (flEtfUiEST GRA IN-TYPE-tlAME PRE -OR- POST] 

(ARGS) 
MODY BODY) 

REQUES T "ITic name of die request hcing handled. 

GRAIN-TYPE-NAME 

' I 'he type of the grain thai the handler is for. 

PRE-QR-PQST ;P«C indicates that this is a. pre-reference handler. :PO$T indicates that this is a post 
reference handler. 



AflC-S 'Hie muncs of the variables pusscd to the handler. TTicr* must be at least one clement in 

this list, lhe Una Afl fi will be bound lo the g- node associated with die request when BODlf 
k cvaluaLod. 

BODY ITic forms thai DOIlStitUlC the handler. "I'hL-y are evaluated with die arguments passed to 

the handler bound (0 the variables named iit AflGS. 

All requests made l)y users have a sinrjlc argument, the name of the module Ihul 'iii: request is mlfinded fof. 
Handlers may also make rcqoesK and these requests Can contain more than one iLrgumCnl. The hiindiere for 
the :LOAD+ bind ^ JUCLUDE+ tasks presented in Appcndi* I arc examples of handlers usillft. additional 
arguments. 

Figure S'l contains the request handler definitions fur LispCuinpilaLion and loading, 'ITic llrsL handlers 
invoked when a : COMPILE f equCSl is made on a : LI5P- SOURCE module. It uses ACCESS* to ensure that 
the task Graph being derived models the fact thai ihe iLlSP-SOURCE gfiins an the module need 10 be 
compiled. 

The second handler is, invoked when a : LOAD raqin^S* is made on a : L I SP- SOURCE module. lhe first 
dling that the handler does is to initiate a : COMPILE request on each of tllC grains in the : LISP-SOURCE 
module, and then Ll models die fact dl;H the ; B IMARV grains produced by compilation need tn he haded. 

Handlers ensure dint U^t ^r:iph paths exisL Arrer a handler has been invoked on a grain nnec, additional 
invocations will have no effect, 'Jhcrci'ure, task definefS need only he concerned that the proper handlers arc 
invoked at least once and do n>.A need to worry about additional invocations. 

tDEFINE-fiEQUEST-HANDLCR (COMPILE :LISP-SQUF!CE :PRl) { SOURCE -NODE) 
(ACCESS* SOURCE-MODE ((SOURCE : LISP-COHPILE ) BINARY) J) 

fDEFJHE-REgUEST-fiA.flr01.FR {:LQAD : LISP-SOURCE ;PR£) ( SOURCE- NODE ) 
(PROCESS-REQUEST : COMPILE SOURCE-NODE ) 
(ACCESS* SOURCE-MODE {{SOURCE : LISP-CDMPI LE} BINARY 

{BINARY iLlSP-LOADJ-eiM) IMAGE))) 

Fl.|unc 5- 1 - Request Handler De fl nicions for I .isp 

5.3 Reference ] tandters 

Reference handlicrs. realise the implkjadoiii references upon construction graphs. The construction 
implications of a reference depend upon the kind of reference, the request, and which pan of the reference 
in.- ■ :i- 1 l - - • > :ho n-.iiiy.ik" [:,rt>-: [:■■; ■■ ; m. rho .:■.:: i us: helm: us \\ I ach ! mi i ■! I .-r i-: ice nil" cd h; c rcf^eacc 
handler signature that Includes ""V*c fields: the IhTce fields frcsrn the reference, signature, the request name, and 
,i p.jrtic:pj-.ion mjirku (■,■ t/'Cr : SIGHT or ; LEFT). Sample signatures are: 

<< :CALLS : LISP-SOURCE :L15P-£QURCE> < i LOAD ;LEFT>> 
<<rCALLS ;C-SOURCE :C-SOUHCE> <?COHPILE :RI&HT>> 
«;MACRD-CALLS : LISP-SOURCE : USP-SQURCE> <iCOMP!Lt ;LEFT» 

Not all references arc relevant lo every request, made. For instance, the reference 
(iCALLS LISP-SDURCE-I LI5P-5QURCE-2) 

has no rmplicaticuvS when a reqnesi is made to compile LISP- SOURC F - ] . However, if the request Is LO load 

LI5P-S0UPCE-1 for execution, then the reference im plies that LISP-SOURCE -2 needs Lo be loaded, It Is 
also important lo recognise that the direction Of the rclcrencc matters. Kor example, the reference atxivc has 
implications when LI SP -SOURCE - 1 is loiided, hut, it han none wtsen L I SP- SOURCE -2 is loaded. 



Ucfininji Reference I landless 

fteftlBHOC handlers arc de lined with 0£ F I N E - RE F E RE HC E - HAKDL E R. Calk hiiw the form: 

(CFJIHE-REFEREHCE-IIAHDLER ({REfEMNCE LEFT-TYPE RIGHT-TYPE} 

(RFQUEST DIRECTION}) 
{ARGS) 
&BOOV HODY) 

ft f FEREUCE ' I lie nanie of the reference being handled, 

1 EFT- TYPE The grai n ly pc of the left i first J rmKJute b [he reference. 

j&JiJ^r- f W£ ' i"hc grain type of the right {second) miidLile in the reference. 

REQUEST 11k name ufuta request being handled. 

DIRECTION liither ; LEFT or r RIGHT. 'l"his field identifies the module that the roquesE being handled 
refers to, 

AJJGS The Ei-ujitCS of ihc v^Ficihks passed to the handler, these wiEl be hound when BODY is 

evaluated. Iticnc must he at least two elements in Jim list 'I'hc first A#G will be bound to 
ihe left gr.din of the ncfcrtnLc. Jhc second AUG will be bound i.y the right grain of the 
reference. 

BODY '['hi- forms, thai constitute the handler. Ihcy arc evaluated with the arguments- passed (o 

ihe handler bound to the variahlcs named in ARGS. 

Yignic l>-2 enntains reference tuindlcr dcfl nitrons for Lisp compilation and blading, the fim handler 
mndcls the fact Ihitt the grain represented bi CAl t ED-NODE needs to be leaded, and that Ulc resulting 
: LISP- IMAGE grain plays die role DEFINITIONS in the compilation of the grain represented ty 
CALLIN&-NQOE. The second handler ensures thai the grain represented by :CALLED J HOUE is loaded. 
Note, while these handlers arc sufficient to handle the commun PUKJulc interactions For Lisp systems, Ihey arc 
not sufficient to handle all uf the ways that Lisp modules may interact, More handicni would need to be 
defined in order 1o properly handle all of die wa^S that l-isp modules can intcracL The prototype 
implementation of UUl.l>docs not include these additional handlers at thin dm*. 

BLILfj guarantees th^t reference handEc-re arc invoked after pre-Teferenee request processing .md Therefore 
handler writers may safely asfarmc that Lhc cfferLb of pre-ie Terence request handlers will already he present in 
the graph, h'or example, the :KACRO -CALLS handler discussed above assumes that Ihe compilation of 
i a i i .Nfi-MJME h:isal:ead; been rruideled. 

5.4 A 1 ask Description Definition Ex ample 

"ITiis section presents an example of a Uisk description definition. 'Ihe task defined is called 
: L I ST - SO JRC E -CODE and il * ill produce formatted source code listings for a : L I 5 P - 50URC E mod ule and 
aoy jLISP-SOURCE modules that it rcfcrcncei. All of [he defining forms for ; LIST -SOURCE 'CODE arc in 
figure 5-3- 

Hist, the J LIST- L ISP- SOURCE process type is defined, Instances of [his type hare- a sin&le input role 
called SOURCE and a single output role called LI ST INC. 'Ihe function LI ST -LISP-FILE b Called to 
produce the grain filling the output role from the grain filling the input role. The request handler for the task 
Is W!T>' simple, it models the foci that the stmmc grain to he listed will play the role SOURCE in a 
:L 1ST -USP -SOURCE p-nodc jnd thjit a jj-nodt should be iliuichcd to the LI ST IMG role of th.it same 



p-nodi. "Ilir iwo rtltirncc handters specif")' tllat gfii'mn wbiuh arc ciiJIcd ty a URihl hiing IihLlu" should 
Lhcmsclvra; Ik lasted. 

: LIST -SOURCE -CODE Shssws Ihc vdrtw ttniCCprnj sySLCffl ffiuKlrls ittparjlc frutn infinrmilbn about 
tittto: miec iw denning. fturirK an evaluated, formatted lis«ia|ii ma>- he- -iibLiLiiicd for any pre*u»usly m<Mic]ed 
Lisp system wtllLHfL alicrlngiiny syxlcm mfjdcft, 



(DEFEHE-RErERENCE-NANDLER ( ( :MACRO-CALLS : L I SP -SOURCE :LI5P-S0URCE ) 

(:£0MPILE iLEFTJ) 
{CAU1NG-N0UE CALLEDNCOE) 

(PROCESS-REQUEST :L0AD CALLED-NQOE) 

(PUSH (ACCFSS- CAi I f.D-NjQBE ((SOURCE :LISP-CDMPILE J BIHAR* 

{BINARY :LISP-LDAD-BIN} IMAGE)) 
(ACCESS* CALLING-NODE ((SOURCE :l_rSP-CDMPII F ) DEFINITIONS)))) 

(DEFIflE-REriRENCE-HANDLER ((:CALLS ;U5P-SQURCE :LI5P-SQURCE) 

( :LOAD :LEFT)) 
( IGNORE CALLED-NODE) 
(PROCESS-REQUEST : LOAD CALLED-NODE)) 

higpw 5-2; Reference Handler Dcfiiti lions fur I Jsp 



(DEFINE-PROCESS-TYPE :L ]ST-LlSP-$OUHCE 
((50UPCE :LISP-5QORCE JINGLE)) 
((LISTING : PRESS : 5 INGLE SOURCE)) 
OUTPUT -STREAM 
{FORMAT OUTPUT-STREAM "-SLIST ^A* 

( PATHNAME -MI*HJS-W£ «S ION SOURCE) ) 
(FORMAT OUTPUT-STREAM --^LISTING -A h SOURCE) 
(LIST-USP-FIU SOURCE LISTING)) 

{OEFINE-ftfOUtST-HANOLER f : LIST-SOURCE-CODE -LISP-SOURCE : PRE ) 

(SOURCE-NODE) 
{ACCESS* SOURCE-NODE ((SOURCE 4LIST-LISP-SOURCE ) LISTING))) 

(CEFIHE-HEFERENCE-HAJJDLER ( ( :WACRO-CALLS :LISP-S0URCE :LISP-SQURCE) 

( iLTST-SOURCE-CODE aCFT}} 
(IGNORE CALLED-NODE) 
(PROCESS-REQUEST : LIST -SOURCE-CODE CALLED-NODE)) 

{DE TINE-REFERENCE -HANDLER {{;CALLS :LISP-SOURCE : LISP-SOURCE ) 

(: LIST-SOURCE -CODE ;LEFT}) 
(IGNORE CALLED-NDDE) 
{PROCESS-REQUEST ?LI5T-S0URCfc-CQDE CALLED-NODE)) 

FlgJurtM: Dcfiniliun Fur jLIST-SOURCE-CODE 



6. Reprise 



'this chapter high lights several aspects oniUIIJ^ that have been presented in this report, The first section 
summarize* how Hi : ll l* uvcrcuoie* the difficulties avsociatcd with existing tools (see chapter 2). ITic second 
•sectiun discusses 1SUM -la's construction framework and how it provides a banc far describing new Lists within a 
suiiic framework that conceals, many hv* level details, from the Uisk definer. "ITic Jinal souiun proposes ways 
that Mil 1. 1> could 1)0 CMCndc-d to provide capabilities nut found in exiting tends. 

6.1 BUILD Compared With F justing Tnols 

I'hKiscd irt terms flf inkT'iintrlule relL-rtrtts. lite ntJIEl) system miKklmg mechanism allows users to 
desenbf fysjems in 1erms true :irc natural far them. Fll'll 7> -:-Ar.m lnodels are easier to understand and they 
provide irnwc information dun the cunsLrucLion directive- liSLS used by csistinft tools. 

User deflnahlc tusk JescTirjtion.s, hlIi.ij'k usi description mechanism is responsible for die Fact thai HUii.n 
is not constrained to sumf embedded set of tasks. Ity separating system models and task descriptions. IW.It JJ's 
knowledge about construction car be modiFied without requiring that system models be changed. HuwCvcr, 
if a aiew task IS sensitive 1o a class (Preferences previously ignited, then editing models will have to be 
updated. 

InlcrnkHdlaie £niins arc not referenced, The only grains that are referred to in a system *ne the source 
grains that comprise modules. While Intermediate trains, are used in W It IVs task graphs, these grains never 
appear in system models. 

All sounfl- grain* must \k referenced. All of the source grains that participate in a System cither reference 
other stains in the system or arc referenced by other grains in the system. Therefore, since mni.D models, 
encode system referencing pattern^ all of die SouiU- grains in a system must appear in any well farmed JSUtLD 
model of that, System. 

6.2 BUILDV Construction Frara^ork 

bl'illi provides procedures which guide the construction process. These procedures include hooks For the 
■...!: purfii^ ;ii' .;=;:: s.:|i pi: cd ta-^ cctnpijor.s. I:\c set of fixed pruudures take care of Iqy> level znnstrucLirm 
details thai arc common to all tasks and allow task definitions 10 contain just the derails that are relevant to the 
particular task Wing dofhiCd 

Tin; task graph Tcpresentation and analysis algmilhm pnjvlde a uniform way lo describe and perform 
system maintenance tasks- New process types, and gram types. can easily be integrated into t„isV pr^ph.s. 

The ACCESS family tif functions provide a genera] *ay for viewing and m,an:p-ii]atLng cask graphs that 
isolates handler definitions from the low kve] mechanics ofinstanliatlng nodes, matching gram types between 
g-nodes and p-nude pons, and actually linking nodes, together. 

The wit graph derivation algorithm ensures that prc-rctcrcncc reuuest handlers are Invoked before 
reference handfcTS and thai reference handlers arc invoked before rjost-rtfcrence request handlers. This 
algorithm is also responsible tor translating mudulc references mitt a series of handler invocations, one for 
each grain involved ir. ,i rcicrencc. l-'inally, the task graph deflation algonthm ensures that cinctiilar 
references (i.e., (: CALLS A B) (:CALLS B A)) do not causi in finite loops during reference handling, 

Btlll-fi's construction framewurt allows task drfiiKi:. i- • concentrate OH the signirncanl details of die task 
being defined (e.g., what pnicesS and grain type* are used, what references arc relevant and how stumld they 
he handled etc.) and isulutes rJ"iCIVl fn,>m low level details lc.g„ task gniph analysis, node instantiation etc.). 



6.3 Lxlenkioruto HL'ILD 

ISLJItn provides a more graceful way LfT modeling systems than CxisLing, HkiIs, yet It docs not provide 
greater capabilities, lids sectnm proposes extensions let huh ji that would allow iL to preside a *t of facilities 
that other loots do not. 'Ilic; extensions arc auttunatie derivation of system specifications t'nun source ante, 
support fur patching and similar maintenance styles and the incorporation of Lhc naistre of module change 
into Lhc reconstruction algorithms, 



Automatic Derivation or System Dcsaiplk 

The BUII Imiodcling mechanism provides a natural way to describe systems bu t i[ duos not ensu ne that the 
descriptions are complete in correct. Dcsigncra arc still required to nerierate system models by band, A tnol 
that could derive system impels from source code would relieve designers of the chore of building system 
description files. 

h'ur simple languages. an analyzer could build a gjeai deal of Lhc model and locale areas thai might 
present difficulties, Kor example^ in most C Systems all of the dependencies are caused by use of the 
^INCLUDE compiler directive and calls LO externally defined symbols-- lhc reference as&CttionfS from these 
reference* could. l>c synthesized automatically. 

While there may be jiiugi u lurn ing environments in whbcti it is. possible to median i/e the derivation of 
system models diere are certainly Languages for which such dentation *ould become arbitrarily comples. 
For example. hitman develops an argument against automatic derivation of Lisp system models based on Lhe 
complications caused by macros [Hitman 84], 

Patching 

"]T»enc air: many instances where a system maintainer may want to introduce changes into a System without 
making sue* that Lhe resulting. system ^ consistent;, for example, debugging experiments where small changes 
ire introduced EO examine some small parL of the 1 sysLcm. These dlun^CS may net. pe intended to become part 
Of a released system, it may even be known rinLL they will cause -compilation of some other module lo fail, 
An other instance where the ability Lo patch a system is important is when a quiet fix rs being attempted and it 
is important that the effects be seen quickly. This Vind. ofchaogc rcrpresCnLS a tentative guess OH the part of 
the. malouliner. The introduction of such changes into systems must be ■supported by system management 
tools if such tools are goiog to help and noL hinder maintained. 

The DEFSYSTPJul patch facility provides some support for producing inconsistent systems. Unfortunately, 
the DFFSYSTTM pa.lch.ing facility mates no use of the dependency information that the rest of the tool uses. 
No analysis of Lhe effect of a patch is available. Nothing guarantees that a patch will even be loaded correct] J' 
according to the dependency information thai is available. For example if a patch file includes a modified 
macro definition and two calls, to it. the calls will not refer Lu die new version of the macro unless they art 
placed after die definition in the patch Tile by the user. 

System management tools should mate use of system models in order to support panning. Patching 
mechanisms should alsn supply information about the cITcct that a patch may have on the rest of the system. 
In UUlLn, the analysis could be dune by prupagating lhe ctTccfs of a change through a task graph and then 
identifying IhtBC modules dlat *CTC affected by 1hc change hot ignored by the patch. 

More Precise Change Analysis 

All of die tools mentioned in this paper ^including nun n) arc sensitive to the fact lhat time change has 
occurred to a module in a system. However., no attention is paid to die nature of the change. % exploring the 
nature of a change it is possible to limit the amount of processing done when updating systems. 

If source aide is changed in a way that cannot alter its compilation, them rs no reason for die source 
nuKhilc lo he recompiled, l-or eiample. compilation should not he done when soutco code has only been 



reformaticd Of had CrurtmCnliiry added tn it. If a fynetiun is added to a module, bill hep ejusling modules arc 
updated tic CirtlEain calls N i the new function, nuihing should tic done to the Casting, modules. Lint libraries 
ire dependent upon uV first pa^s of Lint, huwevcr, mu«i changes to the first [mbs of I. mi will not affix* [he 
libraries. 

Change analysis con also pro*kte important debugging Informinion. For example, if a module iitEcrfuice is 
changed, bill not all of ihc modules that comain references to dint module arc changed, there is a possibility 
that hiii t rfi.ii of omission has been made. 

Unlike MAKt: and WjII.i*. hhi-svstmm can be extended to include more complicated predicate?; For 
deciding when changes arc significant- There is nothing preventing u IH-I^YSnCM system definition from 
using pursers and Source code cumparison programs, in order to decide when iranKrormatiuitS Should Like 
place. However, no enhanced predicates are supplied with ntiiSYSJTM and none of the UHlSYSTliM. 
descriptions encountered wink preparing ihrs paper included defLmuuns of men spcs:i:ili/cd predicates. 

Specialised predicates can only be useful if they require ks&pniccssing io detenr.ine that a transformation 
can he avoided than applying the transformation in (he first place. For instance, ihcrc in nu point in using a 
predicate lo determine that cLunpilatinn of a module can be ^voided if that predicate requires, mure pruccsisEng 
than the compiler. liUJJ.I) can step around Ihis issue by assuming dim it H a single lool embedded. In an 
:n Unrated environment in which the louls Uut arc used to modify modules can supply information ID HUl.t? 
atKHit Che nature of changes. 

huii> could be extended id provide an interface for communicating inflmnaLion about changes tn 
modules. 'I he information passed to ru,J.i> would include Ihc name of the grain modified, ihc kind of 
modification made, and the name of die new (i.e.. updated! grain. A new class of handlers wiled rkmge 
fmvdhrs would fee introduced lo did in the determination of sigtrrficatii changes by the construction algorithm. 

For oiample, me change assertion: 
(:ADDED-STRUCT QEFS) 

Would inform RUN t> that DE F5 has been changed by adding a new structure and thercfnie modules, (hat rely 
on tJcfS do not have lo be recompiled. Ihc compilation of unaltered mudulcs can be avoided since there is 
no way for 1hem en refer m [he new structure. The assertions: 

( :ADDED-COHMENT DEFS) 

( iRL-FORMAfTEO DEF5J 
imply that no changes, that can aher the compilation of DEFS have been made and therefore no rir 
compilation needs to he done. 

The change handlers would contain listings of how types of ebanges alter (he uay in which grains play 
iheir roles, For Instance, one handler would note thai rcTonnalciiig a piece of scurrc code does not change 
ihe way that It plays the rote SCHJHC I in instances of : L I £P -CONP 1 Lt , 
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I BUILD Definitions For C 

'llicdcfinitmnsuBCd t>y him \i nniUKkl a I .isp ciwincmmcnl have been given in the hudy -nT LhiH repwt as 
cxampilcK. I'hiR appendix contains the dcftniiiuiis used by BUIUj u> nmdc] ji C pnosrdmming, environment. 
'J here air more kinds ctf ownirHiivljr u*cd grain lypK m U^IX ftlvtrtJtimcnls than in l,isp environments, 
hence (here arc mesne {JcfimLlmcn needed k* model all of [tic vmjS LhaE UN3X grain* can refer 10 Cueh tAher. 
CummcnUiiy JiaH been added to highlight (he definitions. 

Grab Type rUfiniLions 

(DEFINE -GRAIIf-TYPE :lfAtC-flfiAHNAR :V) 

(DEFINI-tltAId'TYPI :C'&DUR,C£ :C> 

CfthHNE -UHJtm-IYPt ;C-CWJECT ;0] 

(DC TINE -GRAM-TYPE :C-E*ECLH( tit) 

(DEtiNE 'GRAIN -TYPE : SHELL -SCRIPT : SCRIPT) 

Process Type Definitions 

L->iisMimtd LhaL Hk- tunctkiiiHC-COKPlLE . C-LDAD, and /ACC arc fmiihih't, 

ILiEHmL-PROCESS-TyPL C-COWILt 

((SOtlUC* lOSOUtiCl :S!hfiLEJ <III£lUDE4 iC-SfltKlCt ^MULTIPLE) J 

((OHJ*CT tC-OflJiCT :5INGLE SOtWCI 3 J 

&THEM 

(TORMAT STREAM --JCDMPILE -A" (PAl HhlftMl -N I MLI^ - VF HS \QU SOURCE}) 
{F0ANAE STREAM --WOHPtLmC -*' SOURCE) 
(C-CQNPJLE SOUfiCC OBJECT)) 

,\:i i :ni -i ■:;:::■ vwpf r:-i r-^ 

(iPRIfcrt.RY iC-OBJECT iSJuGLIJ {$F{OtinARY -C-&H.IFC1 : HIJLT!PLE J > 

[ftHfljCE :C-IHCUTE : SINGLE PRIMARY)) 

5 r H F AH 

{EOHMAT STREAM "-ILIIrt: -A -{-1 -*>}- 

(PATHNflME-NlNU^VEHSiaN PflTNARY) 
(NAFtftH C-PATHNflHE-HHUS-VEnSICN SECONDARY)) 
{FORMAT STREAM ' -iL I«H I Nu : -A -{-i -A-)" FHTPUDTf SltOW*flT] 
in-KIAD PRJHAHr SECONDARY IMAGE)) 

fOEFINE-PRODES-S-TYPE VACC 

((ERAHHAH ; t HCC-GFZMWftri : SINGLE)) 

((fARSER :<;-SOuRCE 5[BGLE GHAfWAR > k 

STREAM 

(FORMAT 5THFAH '-XTACC -t>' ( PATHNAME -NlNUS-VEFlS ION G&ANNAR)) 
(FORMAT STflEAN >-lYA«]NG -*- GRAM1AI!) 
(VACC GRAMMAR PARSER )) 



Ktqurat and Kcfori'ncc Handlers 

*lhc request hflndkr For t" ;:nrnpibLLun mude-ls the fuCL that Lbc source grain nccdK :o b\: o::n piled, lite 
cuily neicfCnCC dliU can have an effect nit C ctifttpilatiihll is riNCLUQES- [t'GftAlN-1 includi.-* GRAIN -2, 
Chen GRAI*J-1 indirectly includes any grains thiLLGRAIH-Z includes. The tus!k : I NCLUQE+ (dcwirihcd \atet) 
u. rfepiHisibk for gathering all uf the grains included ifidirccilj 1 hy a giiim u.nd attaching die ctirrespiuiding 
g-nsNJcslOthe IHCLUDES portu-flhc [C-CGMPJLE pTIwJe Fnr the grain being rumpikd. 

in 

}■■ :CONPILE : C ■ SOURCE 

j j ■ 

■ ■ ■ 

iTlil rhl-HigurST-HAMREfl (iCONPUE iC-SOURCE :PRE) { SflUACt - M»E } 
(ACCESS* SOURCE -NWh ((SOURCE C-CCJWHJJl) OBJECT))) 

(DtFIBE-HM*FHNCL-k*ll&LfK ((-INCLUDES :C-50URCE : C- SOURCE J < ;CO»*]Ll -LEFT)) 

(]HCLUD[NC-MOnE 1 HCl UDE ft- NODE ) 
(LIT (JCONF HE-PROCESS (ACCESS [NCI UD1B&-NQDL (4 SOORCE C "COMPILE) ) ) ) ) 
(PUSH ijuciliueu-mOdi (ACCESS* C0HFUCPRDCE5S (INCLUDES))) 
(PROCESS -RE QUE ST : IMCLUK+ IHU (JOED-BODI COhPI L E - PRGCE SS) ) J 

If a :C-5DURCE grain culls unrthof grain. then HULL It pessimistically assumes that iL indirectly Culls, ally 
grain called b>- tiie second grain, 'live task : LDAD+ gather^ all uf the grains called indirectly by a grain in 
nrdcf L11 ensure OTliit the proper «( of Brains is United tifgcthcr. ' I tl-G lack of a taS-V like : LOAD+ in Lisp is due 
i.m ;'•:■ l':!ii ih.i; in I .Up unv:r;inniu:iL-- l-i-:i rr- ,\->: kuidui: inc>: n.i-.,:i : , i.im-z.iri n: hcing explicitly lir.iyjd 
together. 

;;; 

;H .LOAD :C -SOURCE 

::: 

)Mf ISII-HEOUEST-HJtilDLER {:LDAD :C-SQURCE ; PRE ) ( SOURCE - UtoE ) 
{PH0GESS-REGUE5T :CONP[LE SflUHCL-NOOE ) 
{ACCESS" SOURCE -KQPi {{SPUFiCE C-COHPILE) DEJECT (PRIMARY C-LOAD) ItUUjE))) 

(OEIIIIE'HEFERENCE-HAiyDLFn f ( :CALLS .C-SDuRCE :C-SQURCE) { : LOAD :LEFT>| 

{CALLIHG-IODE CALLEB-NODi ) 
{LET ((LINKING- PROCESS 

[ACCESS CALL IK- WOE ((SOURCE C -COMPILE) OBJECT (PRIMARY C- LOW} ] ) ] ) 
(PIWCISS-HLQUIST j COMPILE CALLED- NODE ) 
(PUSH {ACCESS CALLED^NKWE ((SOURCE C-CQHPHE) WJECT)) 

[ACCESS* LIHKlWi-PllOCtSS {SECONDARY) ) ) 
(PROCESS- HE WEST . 1 DAD+- CALLED -NODE L IKK INS- PROCESS )}) 

(ftEFlNE-REFERENCE'HANDLER <(:C*4.LS rC-SOURCE sC- OBJECT} (:LOAD -LEFT)) 

i CALL ] Nil - MODE CALLED- NODE ) 
{LET ((ItHKlNG -PROCESS 

(ACCESS CALLlFffi-NOUF ( (SOURCE C-«WILE) ODJECT (PRIHAHY C-LOAD-JJ)JJ 
(PUSH CALL ED-ROPE- [ACCESS* LlNtthC- PROCESS (SECONDARY}] ] 
(PHCiClSS-HlOuLST :lDAO+ CALLLD-HDE LUHtlW;- PROCESS}}) 

Sometimes aimp-iled objects are used as source grains {c.g. supplied libraries). These definitions encode 
the knowledge needed to handle the loading uf iC-oo ject grains, 

ttt 

■;t :LOAO ;C- OBJECT 

■ ■ ■ 
pi' 

(DEFINE-FCEOUE 51 -HANDLER ( : LOAD :C-OBJECT :PflE] i| QKJFCI -NQB1 ) 
(ACCI SS* OBJECT -NODE ((PR3NAR* C-LO*P] ]puci))) 



(DEriNE-REFEHE#Ct-HAHI)I.EH <<:CALLS :C-OEUECI ;£-$OUHCEJ { : LMD :L|FI)} 

<CAI | 1HD-N0DE EALLEO-NODE) 
(LET ({LIMING -PROCESS (ACCtSS CALL [K -NOD L ((PRIMARY £-lOAD)))lJ 
(PK0tF.5$-l)tOUE5T :CDMPILf CAl t ( 0- MQfVF } 
(PUSH (ACCFSS C*t I ED-NODE ((SDURCE C-CQWJirj OBJECT J J 

(ACCESS* L EhK me-PR0CE5& fSCCflyOAF)*))) 
{PHOCESS-REOUESl : LDACH CAM I l)-NTOL L ]NKINC-PflMESS) 3 ) 

< QE F INI -DEE ERF. Nil F- HANDIER [(rCALLS :C-OfiJ£CT :t-OiJtCT) { : LOAD : LEFTJ ) 

(LAI I I KG -NODE CALLED-MQQT | 
(LET ((LINKJI«-PnaCtS& (ACCESS CAI I INA-WOCE ((PJUHARV C-LOAEF].).}] ) 
I Pu i.-i i..ai , 1 1: - h •:: m ( acc f *5 i i i m <. ] m kh::;:i ss ■ si ::ci mw n v ■ ■ ;. 
(PRGCES.3.-HHKPES1 slOADf CALLED- NODE LI hlC 1 HC- ^KpCl Sfi}}] 

Hcfc arc the hangers for : I NCLUDE+ and : LOAD+, There aw no request handlers associated frith shrsc 
request a* all «f ihc 5iE,nificanl eonstmcu'un mfcwniaiimi thai !hey imply arista (hum references Thoe 
handlers illuSUHle Ehr use of more thjin twy values being passed D reference handler*. 'iTic uddilipnal 
parameter for : INCLUDE + is the :C-C0Wti h p^miie which models ihc compi Union to be dime. Ihc 
additional parameter to* : LQAD+ e the p-mnde which mudels the Linking to he dow. 



i 1 1 
: ; ; 



:INXLI»l* :C SOURCE C-C0HfIl( 



( tit F I BE -HFFEHtNCE" HANDLER ((; INCLUDES :£-.S<HJHCE C-50UHCE) (: INCLUDE-* il(IT)] 

(IGNORE INCLUOLU-NQm 1UCL UPIHC- PROCESS-) 
(PUSH [KLUDED-NDDE (ACCESS* I HCLUDINC- PROCESS (INCLUDES))) 
(PFt«F.55-RtgUE&T :INCLUD£* INCLUDED -HDD! INCLUDING- PROCESS)) 

E h I 

;:; LOapt :C -SOURCE C-L0AO 

; ; ; 

(KflNI-ftEFEBtNCE-HAHOLEfl (( :CALl£ ;C-SOUfl<e iC'SOURCEf ( : LOAD* :LEETJ) 

( I CHORE CALLED- HQOE LlNRlNG-HRacf 55J 
(J"FtQCES5 -REQUEST :COMPILI CAtLln-W)pE ) 
(PUSH (ACCf$£ C*ILFU-M0D* ((SOURCE C-COWlLE) OBJECT r) 

■I ACCESS- LlNfclUG-PRbCtSS (SECONDARY))) 
{PROCESS- RE QUE ST : LOAD* CAtLED-HOd* L 1N|C INC- PROCESS J ) 

< DEFINE -RE FERE MCE -HANDLER {{: CALLS ;C-SOUREE :C-OBJ£CT) (:L*Afl4 ;LEfTJ) 

(IGNOfil tJIMID-WDE LINKING -PROCESS) 
(PUSH CALLE0-»&P4 [ACCE5S-F L IN* ING- PROCESS (SlCOHOAPf } i} 
(PROCESS-ACQUEST :LOA[H- C«l I Fn-NQDE LlhKIHG-PRDCESS)) 



- - F 



F F F 



:LOAD* lC-WJICT C-LOAO 



fOEFIHE-REFEREkCt-DAHIiLIR {{;Cft.LtS :C-OBJECT iC-SflUFCE-) | : LO"HH :LEFT)) 

<I(3N4.KI CAUIO-HDDE LINK1NG-PSQCESS) 
(PfiflCESS-flEOUEST zCDHPILE CALLLD-NDlJF ) 
(PUSH (ACCESS CAIIII1-KWE ((SOURCE C-CONPIlE) OBJECT)) 

hccfss- iiNkinc-pfiocrss {Secondary))) 

(PFte-CF 55 -REQUEST : tOACF* CALLED-HQOF LINKING,- PROCESS)) 

(DFFINE-REFEREMCE-IIANDLER ((:C*LLS :C -OBJECT :C-OBJCCT) {:LOAPt : LEFT)J 

{[GKMU (Alt ED- MODE LIIMING- PROCESS) 
(PUSH CALLE0-KO0E {ACCE55+ LIHKJNG-PMCL4S (5*C0NDARr p)| 
(PROCESS'DEOUEST jlOAfrf CAll EO-NODE L EKKl NG-PRDCESS) p 



Here arc Lhc definitions u-rfd to ITHVdol VaCT's intcraclkrfi fciEtl C S)>SLOTn}i. I he handlers Laptuk' ftc fact 
Lhai Y\CCEIflmmara mi\y include and Gill (WlPC* gxains. 

rlTftCt ;lfACC-£fl«MA* 

(DiriiE-BinUEST-HJIlintElt J .YftCC : YACC-CPAWKAH ; PHI J (GP.AWlAR NODE) 
(ACCESS' GGAHHAR-MODE {{CRAMHAR YACC) FAHSEfl])) 

;|j :C0«FtLL ■YACC-GRANHAR 

i : ■ 

( Dir T. HE -Ht QUI ST -HANDIER I. . CCSMP1 1 r :Tf*CC-CiPfl*liiftp ;HBhj (GRAHHAfl*HQDE) 
(PRDC^s-RiOutST :VACL GRAWAR-NODI) 
(ACCESS* GBAHMAR-HQDL [{CRUMAH YACC) PARSER ( SOWCL C-CDHPTI E) OBJECT))} 

(DEFlPlE-filHRFNCl-HANDl.Efl {(:II«HJDI5. ; ¥ACt-GRANNAl :C-&OURCE} (:CWP[U i U Fl } ) 

jlkKIUUlNG-HlDDE IHCLUOED-NOOn 
(LET ((COMPELE-PflOCtSS 

(ACCI1S IKI.UDENS NODE ((CRAPMAH rACC J PAGStft [SOURCE C-COWPU t}))}) 
(PUSR lUCLUDEO-KODi {ACCI S-S-* COMPILE -PROCESS ( 1NCIUUE J J J > 
(PROCESS -RE DUES* ::|NCAUDE+ IiClUDED-P»DE COHPH I -PROCESS }}1 

:LQAD ;TflCC-5FE*liUfl 

(DiriKE-fitnUFEiT-lwmnLE'R | l Dftl> : YACC'&PAHRAR : P H F 1 CC-RAHPlAR-yOOE) 
[PROCESS -REQUEST iCQHPILE CRAHHAR-NODF ) 
(ACCESS* GRAHHAH-HOUt {[CHAWUR YACC) PARSER 

{SOURCE C-CMPILEJ OBJECT 

{PRIMARY C-tOAQ) IMAGE))) 

(HriWE-fltft FIE *CE -DAWDLER (f: CALLS iTACC-fiMMMAR :C -SOURCE) ( ; LW» ill FT)) 

{CftLi.mP-NDDi 1 calleo-hqde] 

(LET ((LINKENG -PROCESS {ACCESS CALLIM&-RO0E ((GRAMMAR: TACC) PARSER 

(SOStfCf C-CDHPILE! CJBJtCT 
(PfllHAHY C-LCM*))))) 
{ PROCESS- RE 0UF5T ■ COMPILE CA.L LED- NODE ) 
{PUSH (ACCESS CALLED-NDOE ((SOUHCl C-CWPILE) OBJECT)) 

(ACCESS* LINKIWD-PflOCFSS (SECONDARY))) 
( PROCESS -RE DUES T ; [ QALI- LiULED-FJODE LENKIHC-PBOCfSS) ) ) 

[ DEUJIE-BEFERE IK E -HANDLE Ft {(; CALLS iYACC-GRAWAP :C-OPJECt) OLOAD :L£FT)) 

{CALLIUG-NODE CALL ED-MODE} 
(LET ((LINKING,- PROCESS {ACCESS CALLING- HOT" ((GRANNAR VACC) PARSER 

(SOURCE C "COMPEL E) OBJECT 
(PRTHAflT C-LOAD))))} 
(PUSH CJRU H]- HMH (ACCESS* L I HK INC- PROCESS (SECOHOARt) ] ) 
(PROCESS- RE QUE ST : LOAD* CALLFD-NOOE LINKIHG-FRQCESS) ) ) 



Here fire- the defimitiLin* atxd to handk : SHELL- SCR I PI grains. A K-quwi uuMmpik or lusd a sre-ll 
-:. ri ■<•. is interpreted m int-an Uul jEL of die muduks. culled by the script stiraitd be annulled or loaded. 

EIE 

SiS .CQWILE :SHLLL- SCRIPT 

I DE F r N t -« L F h RF NCE - MA HtJ I lit ((.CALLS : SHELL -SO HPT :C-50URCE) ( : EOHPILE -LETT) |i 

(IGNORE CAL LEO- NODE.) 
{PROCESS- HE QUEST : COMPILE CALUP-HMH. ) i 

(DEFIHE-FLFElt(ilC(- : HAiOLIR ((:CALL3. : SHELL -SCRIPT :C-OFJJECT) {: COMPILE iLEFT)) 

(IGNORE CA1LEB-N0DE] 
(PROCESS «E QUEST :CDMFILl CALLE D~ IfWE ) h 

\m- Ikl -HI MKIFJC. HAMQLCP (( CALLS : ShLLI. SCPI^T Vfl;; GRAHNAH | (COMPILE : I. E F T ;. ; 

(IGNORE CALLEO-HODE] 
(PR0CE55-SiEQUf5T ;t(JMP|!F i.: Al I ! D- w5« ) > 

::: 

:f f ;LQAD SHELL-SCfilPT 

■ a ■ 
IM 

fDEFIMf-FFFfltFNCE-HAUDHH: ((:C*lLS ! Jul Lt-SCft i PI . C ■ SOURCE J {:LOJU> LEFT)) 

(IGNORE CAL LEO-NODE] 
{ PROCESS -RE QUE ST : LftW CALIED-IWE )} 

{DEFlHI-RErERENCE-IIANDLER ((:CALL5 : 5HELL-SCREPT :C-0FIJECT> { : LOBO :IE*T)J 

(lr.NDHt LftLIHJ-NODl) 

(PROCESS -RE QUt ST :L<MW CAi l t 0- WMJC > ] 

(OEFINE-HEFE RE NCE -HANDIER [{:CAUS :5HtlL-SCHjPT : YACC-HRJLWHB) ^LOAD lLEFT)} 

(IGNORE CALLED NODE) 
(PROCESS -RE QUEST ; LOAD CALLED- WOE | ] 



